Jamie Allen, Typesafe‘s Director of Global Services published an interesting point of view on Twitter:
And he’s right of course. We are constantly reminded of the fact that we should support FOSS projects on which we depend. Just recently, Wikipedia had this huge banner on top of it, asking for money, and we probably should. But do we really depend on them, and can we really make a difference? Let us look at the problem from a business perspective.
There isn’t a second Red Hat
About a year ago, there was an extremely interesting article on Tech Crunch by Peter Levine, partner at Andreessen Horowitz who have just invested $40M in Stack Exchange. The article was about Why There Will Never Be Another RedHat: The Economics Of Open Source. It compared Red Hat’s and VMWare’s market capitalisation and revenue with that of Microsoft, Oracle, or Amazon, showing that even Red Hat is a rather insignificant competitor in terms of these size metrics.
Why is this so?
Let’s go back to Groovy: There are probably tens of thousands of Groovy developers out there who have simply downloaded Groovy and then never again interacted with the vendor. It probably wouldn’t even be wrong to say that many developers weren’t aware of Pivotal having been the main sponsor behind Groovy. Sure, Groovy is a strong brand, but it is really “everybody’s brand”, and thus: nobody’s brand. Not being a strong brand, it attracted only techies with language interests (and it is a beautiful language to work with, indeed!)
Now, Pivotal has withdrawn their engagement from Groovy, for completely understandable reasons. Let’s review Jamie’s point of view:
Pivotal’s move to end support of Groovy is a stark reminder that enterprises who depend on FOSS projects should help support them.
Would it have mattered if “we” had supported Groovy?
Perhaps. A Groovy Foundation (similar to the Apache Foundation, or the Eclipse Foundation) might have made Groovy a bit less dependent on Pivotal, and this can still happen. Possibly, a couple of larger companies who depend on Groovy, or Gradle might chime in and become Silver or Gold or Platinum Sponsors, or something like that. Perhaps, Gradleware will seize the opportunity and “buy” Groovy to become THE Groovy company.
But will it work? Does the same work for Typesafe? Can monetising an Open Source language and platform work in times when even C# is now given away for free?
Red Hat can make money off Linux, because Linux is a very complex ecosystem that just requires a support subscription when you’re running it in production. No bank on this planet will ever run a server farm without the vendor promising 24h support with under 1h reaction time. But is the same true for Scala, Groovy? The “critical” work has long been done by the developers. The binaries are built and shipped onto production where operations takes over. Operations couldn’t care less if that binary is built with Groovy, Scala, Java, Ceylon, Kotlin, Fantom, or any of the other gazillion Java alternatives. All operations will ever care about is the JVM, or Weblogic – and the database, of course. And operations is where the long-term subscription money is, not development.
This doesn’t mean that no one should make money from developers. Companies like JetBrains, ZeroTurnaround, or also ourselves, Data Geekery show that it works, on a much smaller scale. But if a company is “selling” a programming language that doesn’t immediately help them upsell their customers to buy their significant other subscriptions, you should be wary as the vendor motivation to produce the programming language product is very unclear – and in the case of Pivotal, “unclear” is not even close to describe the vendor motivation.
Good examples of holistic platform strategies are these, because operations and the end user can immediately drive the decision chain that justifies the language lock-in for the developers:
- C# -> Visual Studio -> SQL Server -> Azure, etc.
- Java -> JVM / Weblogic -> Oracle Database -> Oracle Commerce, etc.
OK examples are these, although the upselling potential might not be viable enough to maintain a whole ecosystem. We’ll see how it works:
- Kotlin -> IntelliJ
Less good examples are these, because the value proposition chain is really not obvious. There is no justification for the language lock-in:
- Groovy -> Cloud Platform ??
- Scala -> Reactive Programming ??
- Ceylon -> RHEL ??
The Business Model
Jamie Allen’s Tweet shows a lot about what’s wrong with many Open Source vendors. While he claims that end users depend on OSS products from their vendors, the opposite is true. The end user can simply fork the OSS product and lead it to a graceful end of life before replacing it. But the vendor really depends on the goodwill and the benevolence of their FOSS communities. The vendor then tries to leverage goodwill to make a weird-sounding upselling between completely unrelated products. This cannot work.
So join us in our endeavours. Make Open Source a business. A viable business, a business driven by the vendor (and by the market, of course). A business that makes sense. A business that involves dual-licensing and reasonable upselling. A business that uses Open Source mainly as a freemium entry point for the actual business.
You can be romantic about F(L)OSS in your heart, that’s OK. But please don’t depend on it. It would be too bad if you don’t succeed, just because you ran out of money from your “sponsors”, because you didn’t care about the business aspect of your product.
Read also 5 lessons for any open source business transitioning to a revenue-based model
In the last paragraph you refer to Jamie Oliver’s tweet. Guess you mean Jamie Allen? :-)
Yep, thanks, fixed. I guess I was just a bit hungry ;)
This is an excellent article, which every open source developer should read.
I’ve lost count of the number of times I’ve had discussions both online and offline with open source proponents.
While yes it is possible to make money from open source, it requires skills beyond programming, and requires a business plan better than
1. Build software
2. ???
3. Profit
Most developers are missing these business skills, and there is a cronic shortage of people actually valuing their time.
Thanks for the feedback. Yes, those ??? are really the thing. Kind of like…
As an open source developer, I think we ought to just charge them. Nothing prevents us for charging for a download, or a binary. I would note that although I wouldn’t pay extra for getting the source, I will, and have, paid for open source (Synergy+).
I don’t think it’d be healthy for every product to charge like synergy, if every piece on the OS charged my distro would cost hundreds of dollars (talk about it like it’s worth that) but think about how much money Linux would generate if we had decided to charge $1 per OS install, and only attempted to enforce that for corporations. Having worked for corporations that run things like CentOS but never contribute back…
I would like to note that I know Synergy+ has problems making money, I feel this is in part due to repetitive desire not to charge. For example first he just asked people for an arbitrary donation, now he’s offered lifetime membership for a one time payment. Neither of these are sustainable. The first doesn’t communicate to people what you actually need to make a living, do you need $1 from everyone? $20? the second has the problem that it’s not reoccurring.
Price wise I think most truly outstanding projects could do something like $1 a month, or $5 a year. I would certainly pay between $1 and $20 a year for my Linux Distro’s of choice, I currently have started using smile.amazon.com to contribute to Arch Linux indirectly because they just need to keep the server lights blinking and I can’t pay them to keep on fulltime devs.
The answer is sometimes charge them. If this is being used in my own personal home project forget about charging me, I’ll find a free way of doing it. If this is being used in a commercial product I’m producing, then be realistic in your pricing and charge away. Lets say I charge my clients $1000 a day, you sell me something for $1000 which then saves me 2 days of work it’s a win s far as I’m concerned, esp if I’m charging the client on a fixed rate.
The only thing you need to remember when working out what to charge me is the value you think I will assign to the software you’ve written. Not what you think I should be paying for it.
Good article (as usual), but it suffers somewhat from the “there’s only one right answer” syndrome.
I’d rephrase it as “Open Source needs better business models, AND it needs more support”.
I would argue that plenty of open source software clearly needs a “true” business model, and that it makes sense (for both users and providers/developers) to do so.
But at the same time, I think there’s also plenty of stuff that really belongs in the “free as in beer AND speech” mode, AND that we collectively should get off our duffs and support it. I personally put a little money every year into something “free”, and I’m pushing my corporate overlords to do the same. Doesn’t even matter so much which it is (one year I pick wikipedia, another year I pick some fanciful java tool, etc.).
It’s like brushing one’s teeth, or helping little old ladies across the street. (Me, I take shopping carts that were left in handicapped zones and push them back to the store. :-) )
I don’t think it’s any consumer’s fault. If there is not a very clever and clear strategy to monetise on any of this OSS software, then it’s doomed to fail. This doesn’t have anything to do with OSS, actually. You can throw a commercial product out in the market with no business plan, no visions, no strategy, and just enjoy the beautiful tech, and then fail miserably.
It’s just that OSS has some of that “free speech”, “better world”, and “we’re all in this together” connotation, which sounds beautiful, but is just really not the truth at all. In the end, consumers just want some component that works in their supply chain. They (mostly) don’t care how it is manufactured. And they want a vendor that guarantees it will work also in 5-10 years. And if the component that works and that will still work in 10 years is available as in free beer: Jackpot.
I do the same. But that’s really nothing more than a symbolic token of appreciation and has nothing to do with helping anyone sustain anything even remotely close to “business”. And what bothers me most is the fact that there is always a deeply implied guilt accompanying these deeds. Similar to selling of indulgences. I don’t want our customers to feel this way. I want them to feel like winners. Like they deserve everything and owe nothing.
Before this (jOOQ) was a commercial endeavour, I used to be on the other side of the fence – receiving those tokens. Yes, they made me happy. And yes, they were ridiculous compared to the amount of work I had invested. And most importantly, they were utterly ridiculous compared to the amount of added value at the consumer side. But I take that as my fault – having chosen the wrong model. Now, we make the rules. And the rules make everyone much more happy, because the rules imply that the vendor will still do their best to support the component in 5-10 years.
Perhaps you could show an example of something that really needs the “AND speech” part? And then, I’m interested in your explanation about why we’re the only industry naive enough to believe in such a thing – I mean, no hardware / chemicals / etc. industry would ever question their supply chains in a similar way.
Hmm. For starters, let’s be clear that we’re having the same argument.
I completely agree that, in most cases, OSS needs a clear monetisation strategy. As one wit said, “Open source is not a business model; it’s a business tactic.” And that the “romanticization” of OSS can blind people to this.
But that does not prove that this is only way for an OSS project to succeed, to become an important part of the ecosystem. (And, as you yourself suggest, part of the beauty of OSS is that any given project can be turned into a monetized business if the need becomes apparent.)
Examples: EMMA. And, arguably, Eclipse. At totally different ends of the spectrum.
The “hardware / chemicals / etc” argument is somewhat disingenuous. If we had free Star-Trek-style matter replicators, the chemical industry would be completely destroyed and rebuilt as something new. And the very same questions that apply in OSS would apply there!
Another example: Linux adoption grew rapidly long before Red Hat became the (relatively speaking) large company that it is. Companies make a profit in two ways: by increasing revenue, and by decreasing costs. I suggest that your argument is mostly around the revenue side. Many companies adopted AND CONTRIBUTED to Linux (for example) because it was a clear win-win: a shared reduction of costs across large parts of an industry.
I generally prefer data over theory, but here’s a theoretical angle: think about the “tragedy of the commons”. Now think about its inverse: “commons grazing” was practiced successfully in many countries for many years, because there was a common sense of what was needed to preserve the commons. Was “the commons” a flawed model? Yes — and no.
I think the larger point that (hopefully) we can agree on, is — choose your OSS business model carefully, and based on reality. Keep your options open, because everything changes (often quickly). Neither pure Romance nor pure Capitalism is The Answer.
I think we are having the same argument, and I largely agree with what you say. I actually even thought about “matter replication” when I wrote the hardware / chemicals argument :) Such an invention would completely destroy most industries, probably for the good of progress and of mankind as a whole (e.g. free medical supplies for everyone). In a similar fashion, something like cold fusion would unsettle the whole Energy-Military complex.
OSS – to some extent – is doing the same to our industry. Giving us almost infinite productivity at almost no cost and the labour, well, that is “contributed”. That’s the theory. In practice, obviously, political interests will govern what appears to be part of the “commons”. Take SQL, for instance. SQL was standardised in ISO partially to get rid of QUEL (I’m referring to something I’ve learned from Andrew Mendelsohn from Oracle, at OOW14). There’s absolutely nothing right or wrong behind the motivation of creating such “commons” and “common property” or “common interests”. The only thing that can definitely be said about it is that it is inevitable.
That is not the beauty of OSS. That is the beauty of innovation. This is in no way connected to OSS. You can have an idea of a new wooden toy for babies. If it works, you can make a business of it. Or keep it a hobby.
In a larger context, I’m not sure if any of what you said implies free as in freedom as a necessary means.
Chuckle. Well, at least we’re down to the quibbling part… :-)
I would argue (and of course cannot prove, not without a time machine!) that the openness of Linux was NECESSARY for the success of Unix. I lived through the Unix Wars, and it was a nightmare. There was (I believe) never going to be one “winner”, one “standard”, otherwise. If I can use a single data point as proof, that’s a proof that sometimes open is necessary.
I’d also argue that OSS is fundamentally different than the wooden toy example: when something is open, it’s easier for *anyone* to make a business out of it, if the need and customers are there. (E.g. MyEclipse.) (That may or may not be good for the originator! :-) But it is a *different* way of doing things.
That’s probably true, and it probably was back in the days of the Unix Wars. “Unfortunately,” I have not lived through those days, so I only “know” from history. On the other hand, considering Google Chrome’s success, I still believe that most of the driving power behind such success is price and quality, and as always, marketing. Or in the case of the iPhone’s success, clearly price was not the driving power as much as marketing.
Well, I’m not a wood manufacturing expert, but I wouldn’t be exactly surprised if an actual wood manufacturing expert merely saw the toy, he might be able to reproduce the essence of it. And I don’t mean this in a condescending way to the wood manufacturing industry.
At this point of the discussion, yes, I agree we’re down to the quibbling part :)
That is a really impressive example :) But I certainly agree with the “may or may not be good for the originator” part, with a strong inclination towards “may not” (see GradleWare, who now competes with tons of individual participants in the market they have created on supporting Gradle).
Long story short: Open Source is certainly inevitable. Even Gartner has acknowledged that. What it means for all of us, we can only guess…
In the mean time, we (Data Geekery) keep losing paying customers whom we’re helping to migrate off Oracle towards PostgreSQL, because that is much much easier with jOOQ.