Is It Really Open?

There is a massive movement in the government right now to utilize open source code in an effort to prevent vendor lock-in.  Vendor lock-in is the issue wherein only one vendor can possibly support a given software release due to the complexity of the customized code being delivered.  Somehow open source is thought to correct this issue… Here is my problem with this approach – vendors use open source libraries to create custom code…that nobody but the vendor understands and can support… Seriously, it is not as if the open source codebases are written as complete solutions – otherwise why need a vendor – and vendors are not releasing their entire deliverables as open source code.  In fact, most open source projects only require changes to their codebases as being releasable back to the public.  In every open source project I have participated in, built, and observed, the open source libraries act as a foundation upon which custom code is built for a given solution. Thus the government obtains an open source foundation on top of which custom code is added to achieve a final deliverable – that only that vendor can support – so why the push for open source?!?

A Better Solution

This challenge of vendor lock-in is not a new one as industry has struggled with this issue for a long time – mainly in regard to vendors going out of business and leaving behind unsustainable code.  In many industry use cases, the solution is to place the delivered code in an escrow account that is held private as long as the company meets its deliverable goals.  At that point the source code, along with industry-approved comments and documentation, is delivered to each customer to enable movement beyond that initial vendor. While that approach is viable from a disaster recovery perspective, the government should have access to much more considering the reality that they fund the development of their solutions on top of paying for sustainment.  To this end, I would propose the following requirements for any delivery:

• Open API Access For Enhancement, Management, and Maintenance
  • One level of APIs would completely open the deliverable to the government for source code and vendor access control
  • The second API set would be a firewalled set, controlled by the government, to restrict what outside vendors can do to a given system
• Modular Design
  • All software needs to be built modularly with defined inputs, outputs, and functional specifications
  • Thus if something needs to be changed, updated, etc… only that module is impacted and not the overall system
  • This is an ideal option for, as one example, swapping out open source libraries over time
• Complete Handoff
  • All of these requirements drive to a discrete handoff event wherein software in built and then delivered with no strings or licenses attached
  • At this point, the government 100% owns the deliverable
  • The initial vendor can then compete, along with everybody else, to maintain, enhance, and manage that software overtime
• Small Sustainment Contracts
  • One of the larger issues right now are the 5-10 year sustainment contracts being handed out to support software
  • Large vendors push for these contracts in order, so they say, to enable them to properly staff up and support these systems
  • By moving to this new model, more nimble providers can directly compete without requiring such massive buildouts
  • To this end, 2-year sustainment contracts with open competes after each term in recommended
  • Better yet would be an ecosystem contract wherein vendors constantly push enhancements and management options to the government and the government only pays for what it decides to use

I am not suggesting this deliverable model for commercial customers as those customers want a completed product to purchase and thus do not get the same rights.  That stated, the government does pay for development and should have this type of system.  Further, a large percentage of much-needed new technology comes from small, innovative companies that can deliver that initial solution but have no real ability for long term sustainment.  This approach overcomes that challenge for the government while preserving the commercialization options for those small vendors. At the end of the day, open source has issues – backdoors, difficulties in spinning up new efforts, and a lack of many advanced features to name a few – but the concept the government is pushing regarding open source software efforts is valid.  I think this concept needs to be evolved into a reality that does not just push vendor lock-in further down the road and place the government in the same place it is today.