Why Opensource is so Goddamn Successful? (even if it's free)

A noble research into some aspects of opensource teams management
Why Opensource is so Goddamn Successful? (even if it's free)
gnus
This is a part of series of my posts related to opensource. See more here.

No one will argue(if you do please contact me, I’d like to chat with such an interesting person) that opensource is indeed a counterintuitively beneficial form of interaction. But why is it exactly so? I have an answer for you, but for that you need to read this article in full. So without a hesitation let’s dive into its two main aspects: communication and motivation.

Communication

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

Melvin E. Conway, Conway’s law

It literally means that company produces the products that directly reflect the communication structure of a company. For example if 4 teams are developing a compiler in parallel then, obviously, it will be a 4 pass compiler(by the way see how reverse Conway’s law works in case of Linux). So structure of communication is crucial. Also, there’s no law for that but it is kind of obvious that the quality of a product and speed of development highly depends on communication quality and speed.

And if we are talking about opensource this also applies. So here’s how opensource is better in this way:

  1. Everyone have access to communication. The threshold of knowledge is very low. And the only threshold as of nowadays is person’s ability to use something like Github. So this immediately rolls us into second point:
  2. Instant feedback loop. Once you hit some critical mass your product immediately gets large and lively community(and automatically motivated one). Nevertheless it’s not just a bunch of people, it’s a properly organised bunch of people, more on that in my third point:
  3. Small core with large edges. Once upon a time there was a Brook’s law, which depended on the fact that in an unorganized group of N people there will be N*(N-1) communications taking place. That seems like exponential growth there and it’s really bad. So how do opensource battles it? Well, in opensource team you would probably see a core team with sometimes one developer and a big contributors base. So while the core team communicates with this exponential pace as it is a very dense communication graph, the contributors doesn’t get to do it because they are only large amount of parallel threads leading to that core graph. So only core team pays the Brook’s law price and its actually negligible. See image below.
  4. Decentralization of actions. It’s pretty much like capitalism or democracy: when you can turn people doing something in their own interests to people also doing something for others this structure emerges: community interested in its own affairs makes far better decisions than one just interested in spending the day in front of office screen.
  5. Treats its users as developers. This means that soldiers in this field have only one type — developer(even though they may have sub types). And what did conventional war art says about this? Yeah, it says that when soldiers are equal and interchangeable — they are the best soldiers. Of course in opensource we have sub types and it’s currently: specialist(which do one thing but good) and generalist(which know the whole project and can do well in multiple areas). But as long as we have specialists, they are pretty good candidates at being generalists over time. All in all everyone can learn and opensource just gives you such an opportunity.
The core team in the middle and contributors on the edges

In detail and more on opensource organization you can read here, from its main provider — the Github.

What motivates them to do this?

There’s actually different kinds of them:

  • Developers
  • Companies

And different kinds of this:

  • Maintain own projects
  • Contribute to other’s projects

So let’s grab some mind and put it into work to answer this questions.

Why does users create their own and contribute to other’s projects?

Motivation of users is a quite sincere one — they simply like it, it’s like a hobby. After a long and dusty day at work their fingers just itching and begging to have some opensource on. Also since programmers typically have enough money it’s totally okay to do some part of work for things that daytime job simply can not give: fame, multi project mobility, sign of making a trail in history, extra feeling of usefulness, making some tool that they use on a daily basis better.

Why do companies create their own opensource projects?

In short:

  1. Opensource enhances quality of the end product:
    – Communication in opensource is, as was said before, better, this means that the end product will be better.
    – You can’t have all good minds working on you. So choosing opensource is choosing from larger pool from which under normal circumstances you wasn’t able to choose. It’s like in sharing economy, but instead of powerbanks the companies share workers.
    – Motivation of users is high and innovations pop up faster and more consistently under opensource.
  2. You don’t get to pay workers, you can outsource them for free.
  3. It makes company much more attractive to potential workers, when they find that it doesn’t hesitate to contribute some opensource occasionally.
  4. It makes end product much more popular. Due to its openness userbase grows like young mushrooms after the rain. You’ll ask me: but how do I make money then? I’ll answer: take a look at subscription model like in Obsidian or at support model like in RedHat.

Why do companies contribute to other’s opensource projects?

  1. It’s economically beneficial. For example: IBM is positioning itself as an IT consulting company and it’s spending millions on opensource. Why?
    An IT consulting company is a complement of IT business, in a sense that one cannot live without other. And there’s this thing that when a price of product falls the price of complement rises: it goes because when price of a product falls there’s more demand coming for it. And when there’s more demand there’s actually more demand on complement because one can not go without the other. So when there’s more demand on a complement it’s price is going up.
    And now about IBM trick: they’re doing this because IBM is becoming an IT consulting company. IT consulting is a complement of enterprise software. Thus IBM needs to make enterprise software cheaper to raise demand, and the best way to do this is by supporting open source. Source.
  2. If a company builds something on top of an opensource project it’s deemed to contribute. There’s no point in battling the master branch. And when you are pushing something into the repo it’s surely going to be automatically maintained and supported till perhaps a Heat death of the universe or even further.
  3. It’s an interesting kind of a training for the team to do opensource. Or even for a single developer it’s very beneficial to see other people’s code «in the wild».

Conclusion

That’s it. Congratulations on your reading.
Now go and make something useful with that knowledge.
Write an article or smth.

Bull image