The four capital mistakes of open source

No readers like this yet.
red pen editing mistakes

How do you develop a successful open source business that lasts? Of the more than 250,000 open source projects on SourceForge, few will be successful at that goal. But one way they might think about how to do it is by doing it in reverse: What should an open source project or business not do?

Download Free eBook

The negative advice has existed since ancient times, from one religion to another. The Ten Commandments are for the most part written as what not to do. We can go for a short walk or drive around our neighborhood: road signs give us, in very short messages we can read while driving, negative advice. Ask Warren Buffett about finance. He’ll tell you “Rule #1 is ‘Don’t lose money,’ and Rule #2 is… ‘Don’t lose money’”.

Open source can also be better understood through negative advice. The latter can be back-tested and endure the test of time. By following a positive framework (but without falling into platonicity), one can slightly increase the chances of success. But by ignoring a negative one, you will most certainly fail.

First negative rule: Reflexivity

Don’t try to sell the same product you are giving away for the same use case.

As a business, open source is built on sequential sets of events. Free software and openness create an economy based on non-monetary transactions. Instead of money, people trade their time and, generally, their mind share in exchange for value. It is the Mind Share Market. As this happens, another economy takes shape that follows the more common path of transactions using money: the commercial market. In order for the model to work, what is free and paid must necessarily be complementary, therefore different. Differentiation is at the core of all open source businesses, and its opposite, reflexivity, is where the business tries to sell the same good that it is giving away for freei. Reflexivity is destructive, as it starves the provider and prevents the business from developing financiallyi.

Second negative rule: Coercion

Artificial fences are self-defeating.

One of the key reasons customers choose open source is freedom. Coercion is the opposite and relies on forcing third parties to behave in a certain way. At its roots, open source exists because customers do not want to be forced. The practice is hence self-defeating, even if it can work on the commercial market in the short run. Coercion is viral: it can over time tarnish the broad perception of open source as a deceiving scheme and may invite others to do so if temporarily successful. Barriers to entry and exit are necessary, but in a Peter Drucker style that seeks customer respect.

Let others deal with legally acceptable deception.

Third negative rule: Isolationism

What works in some contexts doesn’t work in open source.

Ecosystems thrive on extensibility and die of bureaucracy. The ability to access code, to re-distribute it in certain scenarios, and to enable interactions with other components gives open source an advantage not readily available in many business other models. Hundreds of thousands of engineers (potentially one day, billions of people) working together and contributing value can outcompete a large corporation with the same number of engineers on its payrollii. But for this to happen, collaboration must be extremely simple. Observe technologies like Linux, Firefox, WordPress, MySQL, Android or Wikipedia: they make it easy for others to extend their platforms from the periphery to the core; almost invasively. Isolationism blocks collaboration, partnerships, application programming interfaces (APIs), and defeats the purpose of being open.

Fourth negative rule: The salary addiction

Don’t do anything only for money—especially open source.

The last capital mistake requires some context. There are situations where a job and a salary must take absolute precedence over purpose. A job may be “just a job” to support a family.

In other situations people end up in roles they didn’t have to accept, but did so only for financial reasons. Phoniness is the last capital mistake of open source: it is not only immoral, but often counterproductive. People with a sense of purpose would do what they do for free, regardless of incentive. The latter exists, but cannot be the primary driver of action. Matt Mullenweg likes to say that Code is Poetryiii. Poetry is not created on a mechanical assembly line. Passion does not always translate into business momentum. Revenues do matter. But if you see open source as only business you will never understand it.

i. Even Wikipedia, a nonprofit with nothing for sale, does not give everything away. It retains its brand, infrastructure and ad space (used today for donations).

ii. This applies to code and to any other value generation and collaborative work; you are reading this article on

iii. Tagline of the open source CMS Wordpress


User profile image.
Nicolas Pujol helped grow a $10m software startup (MySQL) into a $1 billion acquisition, making it at the time the second largest open source company. He is an investor, advisor to start-ups and author of The Mind Share Market: The Power of an Alternative Currency where he demonstrates the impact of hybrid economies.


"if you see open source as only business you will never understand it"
<em>Quoted for truth!</em>

<cite><i>"Observe technologies like Linux, Firefox, WordPress, MySQL, Android or Wikipedia: they make it easy for others to extend their platforms from the periphery to the core;"</i></cite>
Android is the odd man out among the software projects on that list, due to the restrictions imposed upon OEMs through the Compatibility Definition Document.

Thanks Erlend and Florian. I am not familiar with the Android-specific issues but trust that if it becomes a mainstream debate Google will find a way to make it right. The OS market is competitive....

Someone sent a direct message mentioning that a significant portion of the 250k SourceForge projects may have no profit motive to begin with. Positive side effect: the work done remains and can be shared/re-purposed if licensed accordingly. (software IP in open source not necessarily bound to goals of its creator)

Can you give some good examples from around of projects that you think are handling #1 well and not so well?

Chris: there are 2 ways to monetize open source.

1/ You target the same general user group (different sub-groups for free vs. paid) with a <a href="" target="_blank">freemium </a>model. Most OSS projects faced reflexivity in their early years &amp; those that addressed it succeeded. The best test: look at a project. Do you see them having to hurt their commercial opportunities by making a feature or service free? Do they hurt their community by introducing a commercial offering? If so, they have a reflexivity challenge to minimize. RHEL/Fedora is much better than pre-Fedora, for example.

2/ Another model is called a "<a href="" target="_blank">two-sided platform</a>", where you completely deflect the reflexivity problem. Unlike freemium you deal with two different groups of customers (e.g. ad funded models, SaaS using OSS as core technology). Look how has been able to grow its user base... inherently non-reflexive.

Quote: "Can you give some good examples from around of projects that you think are handling #1 well and not so well?"

Here's a company that's doing great in Open Source. They started out supporting LAMP and now they've grown into supporting numerous OS projects. The company below is their most successful I believe. They also support FreeSwitch.

Read their news section below.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.