TL;DR OSS has conquered the world, forcing even the biggest players of commercial software market to adjust their strategy to this fact. But the original idea of OSS has got somehow twisted in the meantime: everyone uses it, without feeling obliged to contribute. What is more, consumers expect flawless quality, but rewards for providing this quality are very ephemeral (so very few take a challenge). Is such a model stable long-term? Will it prevail or maybe evolve towards something less idealistic, but more pragmatic?

Open Source Software (OSS) has both won & lost in the same time.

It has won, because everyone is now using OSS - individual developers, start-ups, software houses, industry behemoths - literally everyone. In many cases OSS is preferred over more stable & mature COTS products - that was unthinkable (at least for myself) even just a few years ago.

But it has also lost, because reportedly (I've heard this during the recent Lambda Days session by Heather Miller from Scala Center) the rapidly growing number of OSS consumers doesn't correspond to the similar trend in OSS active contributors. We like to use OSS, complain on its quality, but very few of us actually do anything about that (including myself). What is worse, there's a very fundamental root cause behind this issue - very few executives (& other decision makers) in all these companies that use OSS feel any urge or obligation to support (in any way) projects their companies are using ... In their minds OSS is just free stuff with "a prayer support".

Notable exceptions - like Google or Microsoft (that beat the all-time record in contribution numbers) are just that - exceptions: OSS is part of these companies' product strategy.

Holding up the sky

One could just shrug - so, what's new? Wasn't it ALWAYS like that? It was, but (as Heather has very aptly presented during her session - "The Dramatic Consequences of the Open Source Revolution") now we start to see how big & serious the actual issue is ... But before we proceed further - have you heard about Bus (/Truck) Factor? In case you haven't, here's the definition:

Bus Factor is the number of people that could be run over by a bus before a software project would have code nobody is familiar with (or for the project to be neutralized).

src: Urban Dictionary

Simply speaking - the smaller the BF the worse is the shit you're in. If it's 1 or 2, you should start sweating. So, once we have this nice theoretical part behind us, why don't we look at the calculated bus factor for most popular (starred) GitHub projects? You can check them HERE ...

Let's get through some examples (I've made manual checks to adjust the numbers) ...

  • d3 - 2
  • vue - 1
  • electron - 2
  • webpack - 1
  • yarn - 2
  • redis - 1
  • phantomjs - 2
  • babeljs - 1
  • retrofit - 1
  • openssl - 4

Scary, isn't it?

All of these are extremely popular products, used commonly w/o giving it much consideration. Of course "1" doesn't meant that there was just 1 contributor in the revision history. It means that the gap between the activity of 1 contributor & the rest of them is so vast that the impact of the latter ones (even if hopefully very valuable) wasn't big enough to get well acknowledged with whole product's internals.

I'd like to emphasize the last point in the list (this was also covered in Heather's talk I've mentioned before) - the infamous Heartbleed has quite recently clearly proven the potential impact of issues with OpenSSL ...

Foggy future

The reasons for low BF even for such crucial products are quite simple - people are practical: maintaining a complex OSS project is very time- & energy-consuming. One has to earn for a living & doing OSS in addition to regular full-time job sounds unrealistic in a long run. Without doubt, it's also a big honor (at least sometimes), but the price may be just too much to pay.

We can (& should!) preach for increased awareness in the community, but this reminds me some other famous, failed "social responsibility crusades", like water saving, control of environmental pollution, fighting smog, etc. That's why I don't think we'll be able to solve the root problem, most likely the model will evolve, sacrificing some of its lofty ideals for practical reasons ...

Yes, it means its gradual commercialization. Let me describe some potential scenarios (majority of them are actually already happening, and this is just the beginning):

  • "donate button" model - currently the most popular scenario - product creators slap a big, blue "donate" button & the ones who feel that the product deserves it, donate it with some voluntary sum - e.g. via PayPal; sadly, AFAIK barely anyone does that
  • freemium model - this model gets a lot of popularity recently; typically the creators of the successful project create a dedicated company that: builds an enterprise version of the product (with additional features), provides commercial support (for paying customers), builds up the publicity from all the testimonials to increase market attention, etc.
  • build-my-platform model - theoretically similiar to freemium, but the devil is in the details: producer releases the core of their very attractive, key product as OSS, thus making others able to use it for free, but also encouraging their contributions, etc.; still, parts & components that provide real competitive advantage are not shared at all. Examples? Kubernetes
  • tribal model - another variation of the freemium model above - by default you either pay for the product or use the limited version, but if you decide to contribute (at some certain level), you're admitted into "the inner circle" & get free access to the full product
  • "currency" model - something you can remember from ol' good Napster/Direct Connect times: you were able to download X MBs IF & only if you were sharing at least X/N MBs (with N being a pre-configured factor); let's imagine it re-adjusted to the block-chain era: e.g. GitHub could introduce its own crypto-currency - one that could be earned by making contributions & could be spent on using others' contributions - yes, I know that it requires a lot of clarification & refinement, but I find it "potentially" feasible ...

I realize that any of these scenarios (maybe except the 1st one) really depreciates the word "Open" in OSS, but I don't think we'll (as an industry) have much choice - either OSS "industry" will degenerate & wither or contributors will get more "carrot" to make contributing more "commercially appealing".

Pic: “Share” by Tim Peacock is licensed under CC BY 2.0