Since content is king, platform companies (like Google, Microsoft, Twitter, Facebook and Amazon) win by attracting developers to build on their services.  Open source tooling and frameworks are the critical interfaces for these adopters; consequently, they must invest in building communities around those platforms even if it means open sourcing previously internal only tools.

This post expands on one of my OSCON observations: companies who write lots of code have discovered an imperative to upstream their internal projects.   For background, review my thoughts about open source and supply chain management.

Huh?  What is an “upstream imperative?”  It sounds like what salmon do during spawning then read the post-script!

Historically, companies with a lot of internal development tools had no inventive to open those projects.  In fact, the “collaboration tax” of open source discouraged companies from sharing code for essential operations.   Historically, open source was considered less featured and slower than commercial or internal projects; however, this perception has been totally shattered.  So companies are faced with a balance between the overhead of supporting external needs (aka collaboration) and the innovation those users bring into the effort.

Until recently, this balance usually tipped towards opening a project but under-investing in the community to keep the collaboration costs low.  The change I saw at OSCON is that companies understand that making open projects successful bring communities closer to their products and services.

That’s a huge boon to the overall technology community.

Being able to leverage and extend tools that have been proven by these internal teams strengthens and accelerates everyone. These communities act as free laboratories that breed new platforms and build deep relationships with critical influencers.  The upstream savvy companies see returns from both innovation around their tools and more content that’s well matched to their platforms.

Oh, and companies that fail to upstream will find it increasingly hard to attract critical mind share.  Thinking the alternatives gives us a Windows into how open source impacts past incumbents.

That leads to a future post about how XaaS dog fooding and “pure-play” aaS projects like OpenStack and CloudFoundry.

Post Script about Upstreaming:

Successful open source projects create a community around their code base in which there are many people using and, ideally, contributing back to the project.  Since each individual has different needs, it’s expected that they will make personal modifications (called “forks”) of the code.   This forking is perfectly normal and usually a healthy part of growing a community.

The problem with forks is that the code diverges between the original (called “trunk” or “master”) source code and the user’s copy.  This divergence can be very expensive to maintain and correct in active projects because the forked code gets stale or incompatible with the other users’ versions.  To prevent this problem, savvy users will make sure that any changes they make get back into the trunk version.   Submitting code from your local (aka downstream) fork back to trunk is called upstreaming.

There’s a delicate balance between upstreaming and forking.  Being too aggressive with upstreaming means that you have to deal with every change in the community, help others adopt/accept your changes and can result in a lot of churn.  Ignoring upstream means that you will ultimately miss out on community advancements in trunk or have a very expensive job to reintegrate your code into trunk.