Proposal: Open Source Initiative

Open Source, it forms the basis of most personal and commercial software with no sign of a decrease in adoption or change in it's practical use.  At <Company> there is no project or solution that I have heard of or examined that does not use or build from Open Source and I do not think this is unusual or a risk, but a normal operating process to deliver quality software with minimal defects that builds services that exceed expectations and are trusted to operate and handle data securely and reliably.

There are numerous articles on how and why Open Source became the integral building block of modern software (here).  To put it succinctly there would be no Cloud computing or access to reliable, proven software solutions i.e. Linux, etc.  However the ends is not to me the critical component of Open Source software.  It is the means to producing the Open Source software that is the important part and sets the implementation and adoption of software produced as Open Source or users of it as the dominant software on our planet and now recently Mars as well.

Why?  Open Source software while it underpins modern software as a building block is not equally distributed in maintenance and improvement.  How and why is this true?

Currently there are three types of Open Source use cases I have observed and it operates in a hierarchical manner as we are humans and are intimately familiar with these types of organizations in our professional/personal lives.

• Use only:  This person(s) or organization(s) takes and uses Open Source projects to complete their goals without much detail or examination of the source itself.  The practicality of the provided software is the value of most importance to this type of user.  Examples are creating websites using React, deploying Cloud servers using GNU/Linux for the operating system, GraphQL, Postgres, etc.  The vast majority of Open Source use comes from this type of use either directly or indirectly of using another codebase that uses Open Source tools.   The range of users is not restricted to size or composition as Amazon, Microsoft, Google, Facebook, Apple all make heavy use of Open Source projects to build from and supplant their own offerings because it works and is thoroughly tested across more situations and scenarios than any internally produced software could.
• Maintainer: This person(s) or organization(s) is on the outside looking in for a project as far as direction and goals.  They are interested in the details of the source and looking to fix bugs and limitations they have encountered using the source, but do not have architectural guidance and control over the project.  These people and organizations can increase their level of participation and contributions to reach the level of making architecture by building trust and consensus.  As naturally there may be disagreements they can self elect to form their own architecture and steps by forking the project and leading and displaying their designs and goals.  At <Company> this may be the optimal goal for the immediate future for projects with amenable licenses (MIT for instance) that would allow for immediate fixes and architecture decisions to be implemented post haste all the while learning and exploring the remaining code that makes up the project and gaining a deep and thorough understanding of the project.
• Core contributor: At this level the community members of the project validate and work with person(s) and organization(s) to verify and work through their contributions.  They may be assigned to work on particular portions of the codebase or they may be at the point of keeping a coherent and idealized form of the project continuing through the ability to merge pull requests (PR) from a variety of users (could be core contributors, maintainers, or may want to merge with another organizations separate fork as the work is valuable and aligns with the overall project).  Many projects may start out immediately at this level on a personal level and are then sponsored or approved by an organization implicitly or explicitly by the use and value the project code is bringing.  Examples of this are Linux from Linus Torvalds, Redis  (I would encourage use of Redis in all applications for a variety of reasons, but that is for another conversation) from Salvatore Sanfilippo, Bootstrap from Mark Otto and Jacob Thornton, etc.  Case is that a need arises that was not anticipated in their current organization or research and then a general purpose project was developed and it was helpful and useful to the world and then shared increasing the reach and capabilities of the original project beyond what person(s) or organization(s) can do by themselves.

Technical companies that understand the role and importance of Open Source attract core contributors to work for them to continue producing it.  Why?  Understanding the underpinning code libraries and services of what they are running gives them a deep understanding and advantage in leveraging decisions and taking full advantage of the latest software which you are already using explicitly or implicitly.

In this arrangement you are consuming deep dependencies at the application development level because that is what makes the <Company> money and provides growth, the implementation details of the architecture are abstracted by the open source maintainers, but you are tacitly at their discretion if you make no investment to learn and maintain your dependencies.

A rough example say Hashicorp Vault decides that the project would be better served from now on to only work with desktop applications (they would never do this, but this example is contrived) and now all your web services which had used this open source project to do secure secret management you are now in a difficult decision as you have no internal experts that would allow you to fork and continue the project for at least a few years while you can transition and test to new system all the while keeping up with security issues identified.  Other examples of this situation can be thought up for any open source software library such as Kubernetes, etc.

What have other large technology companies done to insure and mitigate this issue while keeping a direct pulse on the community of developers outside of the corporation on directions and core issues?

They simply acknowledge this dependency and hire core contributors to continue making improvements to the library as a safeguard and to keep up to date with the projects and to have access to experts to verify that all implementations at said <Company> are compliant and can extract the maximum multipliers of proper open source code use.

Examples

What I suggest

Hiring core contributors to an open source project is expensive and you will have to justify their work to keep the project up as a full time job under worst case insurance and best case expansion and adoption if they are able to improve developer relations on their particular projects.

There is a risk that these individuals will leave without teaching and enriching your application developers before the cost of their services is amortized.  These individuals are valued and numerous companies compete for their services so this is a legitimate risk (worth it in my opinion if you want to commit to being a technical leader long term).  This approach usually ends in a bidding war usually and like any auction the rationality of the utility you are hoping to get goes out of the expected range of results early.

Instead I suggest that all application developers use 10 - 20% at <Company> of their time maintaining open source dependencies in the libraries they pull and use to create revenue producing software.

Key advantages to this approach

• Knowledge is spread wide across entire organization
• Risk is reduced on every single dependency as developers are gaining awareness of internals that will allow them to maintain forks successfully
• Awareness of <Company> as a sponsor and leader in Open Source communities grows and would be able to attract core contributors that have goals aligned with <Company>
• New Open Source projects can spring forth that will attract other companies and individuals to maintain the software therefore reducing the overall cost of maintaining top notch software.  This would be a runaway success condition, but like the projects above Redis, BootStrap, Linux it happens.