Why Opensource is so Goddamn Successful? (even if it's free)
A noble research into some aspects of opensource teams management
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 hesitation let’s dive into its two main aspects: communication and motivation.
Communication
Conway’s law literally means that a company produces products that directly reflect the communication structure of that 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 the case of Linux). So the 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 the speed of development highly depend 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:
- Everyone has access to communication. The threshold of knowledge is very low. And the only threshold nowadays is a person’s ability to use something like Github. So this immediately rolls us into the second point:
- Instant feedback loop. Once you hit some critical mass your product immediately gets a large and lively community(and an 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:
- 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’s quadratic growth and it’s really bad. So how does opensource battle it? Well, in an opensource team you would probably see a core team with sometimes one developer and a big contributor base. So while the core team communicates at this quadratic pace, as it is a very dense communication graph, the contributors don’t get to do it because they are only a large amount of parallel threads leading to that core graph. So only the core team pays the Brook’s law price and it’s actually negligible. See the diagram below.
- Decentralization of actions. It’s pretty much like capitalism or democracy: when you can turn people doing something in their own interests into people also doing something for others this structure emerges: a community interested in its own affairs makes far better decisions than one just interested in spending the day in front of an office screen.
- 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 does conventional war art say 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(who does one thing but does it well) and generalist(who knows the whole project and can do well in multiple areas). But as long as we have specialists, they are pretty good candidates for becoming generalists over time. All in all everyone can learn and opensource just gives you such an opportunity.
Diagram
The core team in the middle and contributors on the edges
o o o o o o o contributor — one parallel
\ \ \ / / / thread leading to the core
+-------------------+
| *-----* | * core team — a dense graph,
| | \ / | | every pair talks; only they
| | X | | pay the Brook's law price
| | / \ | |
| *-----* |
+-------------------+
/ / / \ \ \
o o o o o oYou can read more on opensource organization here, from its main provider — 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 to work to answer these questions.
Why do users create their own and contribute to others’ projects?
The motivation of users is quite a sincere one — they simply like it, it’s like a hobby. After a long and dusty day at work their fingers are 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 a daytime job simply can not give: fame, multi project mobility, a sign of leaving a trail in history, an 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:
- 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 the good minds working for you. So choosing opensource is choosing from a larger pool, one you wouldn’t be able to choose from under normal circumstances. 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.
- You don’t get to pay workers, you can outsource them for free.
- It makes company much more attractive to potential workers, when they find that it doesn’t hesitate to contribute some opensource occasionally.
- It makes end product much more popular. Due to its openness the 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 others’ opensource projects?
Beyond the economics, if a company builds something on top of an opensource project it’s bound 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 the heat death of the universe or even further.
It’s also an interesting kind of 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.