A Path to Full-time Open Source(mikeperham.com)
mikeperham.com
A Path to Full-time Open Source
http://www.mikeperham.com/2014/10/01/the-path-to-full-time-open-source/
52 comments
I am surprised that crowdfunding isn't a big deal in the open source world. It seems ideal: people pay to get software created or improved; nobody pays just to use it. No restrictive license is required. It seems possible that a developer doing stuff that is both difficult and very useful could raise substantial amounts of money.
Certainly there have been a few crowdfunded open source projects we have heard of, but the model hasn't taken off to nearly the extent I thought it would by now. Anyone care to speculate on why not?
Certainly there have been a few crowdfunded open source projects we have heard of, but the model hasn't taken off to nearly the extent I thought it would by now. Anyone care to speculate on why not?
1. Kickstart some project.
2. Ship v1.0
3. Collect $$$$
Now what? Who supports it? Who fixes bugs? The incentive is gone. Software is a process, not a physical product.
Now what? Who supports it? Who fixes bugs? The incentive is gone. Software is a process, not a physical product.
I totally agree. Everyone who works in software knows that the vast majority of the work, and the money, are in maintenance. I actually built a crowdfunding site that was primarily intended to support maintenance rather than initial development. Nobody used it, though, and I'm about to shut it down. You can take a look if you want: http://bountyoss.com/
I've always thought that there should be a "Patreon" [1] for open source. Companies would commit to paying monthly to an author in exchange for some sort of reward system like getting the bugs they prioritize fixed.
I once worked for a large Fortune 500 that had several well-known programmers who's entire job was to be core-contributors to a popular ruby web framework. They were well paid and had very little oversight.
But given the popularity of this framework, it always seemed a little weird to me to have a single company funding the development. It's also a little risky for the community at large because corporate strategy shifts and an open-source project that was important yesterday may not be important today.
(cf. Evan Phoenix / Rubinius / EY - http://en.wikipedia.org/wiki/Rubinius, Charles Nutter / JRuby / Sun - http://en.wikipedia.org/wiki/JRuby and countless others.)
It seems to me that, in theory, we ought to have a platform for monthly payments to open source developers that maintain projects we use in production.
[1] https://www.patreon.com/
I once worked for a large Fortune 500 that had several well-known programmers who's entire job was to be core-contributors to a popular ruby web framework. They were well paid and had very little oversight.
But given the popularity of this framework, it always seemed a little weird to me to have a single company funding the development. It's also a little risky for the community at large because corporate strategy shifts and an open-source project that was important yesterday may not be important today.
(cf. Evan Phoenix / Rubinius / EY - http://en.wikipedia.org/wiki/Rubinius, Charles Nutter / JRuby / Sun - http://en.wikipedia.org/wiki/JRuby and countless others.)
It seems to me that, in theory, we ought to have a platform for monthly payments to open source developers that maintain projects we use in production.
[1] https://www.patreon.com/
Isn't that what GitTip^W Gratipay is? The reward/prioritization mechanism could easily be added on top of that (or be entirely informal).
https://gratipay.com/
https://gratipay.com/
Snowdift is still being built but I think it's a cool idea for solving this problem: https://snowdrift.coop/p/snowdrift/w/intro
In terms of business, this is freemium. People try out the free (GPL) version, and like it, want premium features, want support, want you to add features etc.
There's a subtle competitive benefit of free: by providing something valuable for free that meets people's needs, there's less demand for an open-source free competitor. In a way, this is a nice reward for helping people; but if it's too effective, it can stifle innovation (by avoiding the pressure on you from competitors to improve).
Now of course, GPL has other benefits apart from free-as-in-beer: you have the code. You can audit it; add your own features; fix bugs. And if the developer gets hit by a bus, you can carry on without any escrow nonsense, incompleteness, unmaintainable code. It's also a business benefit to the developer, as they can get bug-fixes and features and improvements from the community. But because it's only part of the code that is GPL, they only get part of this benefit.
However, typically, the biggest benefit of GPL is bug-reports --- but you still get them from free users who don't have the code. (They won't be as good, but usually the hard thing about a bug is that it exists). You typically won't get much code you can actually use especially if you want to retain sole copyright (though it can be useful to have as a first draft; and have some good ideas). Plus... some people might be reluctant to contribute their effort to someone who's making money (even though they got the code for free).
tl;dr: unsurprisingly, free-as-in-beer is far more significant for a business, than free-as-in-freedom.
There's a subtle competitive benefit of free: by providing something valuable for free that meets people's needs, there's less demand for an open-source free competitor. In a way, this is a nice reward for helping people; but if it's too effective, it can stifle innovation (by avoiding the pressure on you from competitors to improve).
Now of course, GPL has other benefits apart from free-as-in-beer: you have the code. You can audit it; add your own features; fix bugs. And if the developer gets hit by a bus, you can carry on without any escrow nonsense, incompleteness, unmaintainable code. It's also a business benefit to the developer, as they can get bug-fixes and features and improvements from the community. But because it's only part of the code that is GPL, they only get part of this benefit.
However, typically, the biggest benefit of GPL is bug-reports --- but you still get them from free users who don't have the code. (They won't be as good, but usually the hard thing about a bug is that it exists). You typically won't get much code you can actually use especially if you want to retain sole copyright (though it can be useful to have as a first draft; and have some good ideas). Plus... some people might be reluctant to contribute their effort to someone who's making money (even though they got the code for free).
tl;dr: unsurprisingly, free-as-in-beer is far more significant for a business, than free-as-in-freedom.
How exactly does the dual-licensing work in practice?
Can you remain the sole seller of exceptions? That is what is to prevent someone else from forking your project and then selling the exceptions?
I've always suspected that in order to make it in Open Source you have to be highly socially active. (seems like a requirement for everything these days)
Otherwise, someone who has more social capital(active forum(s) presence, blog(s), SEO etc) can sell/support your GPLed product perfectly legally and make a good living from it while you starve.
Let's imagine a ridiculous scenario: someone takes Firefox, slaps their own logo/branding, maybe makes some minor code changes, maybe not and sells this product (source code is still freely available to this derivative product). This actually has happened before(citation needed).
The main difference between your tiny OS product and Mozilla one is that Mozilla has tons of social capital and anyone trying to charge something ridiculous for a Firefox clone would be laughed out of Internet.
For example, there were people selling various GPLed products on eBay and as long as source was included there was nothing illegal about it.
Can you remain the sole seller of exceptions? That is what is to prevent someone else from forking your project and then selling the exceptions?
I've always suspected that in order to make it in Open Source you have to be highly socially active. (seems like a requirement for everything these days)
Otherwise, someone who has more social capital(active forum(s) presence, blog(s), SEO etc) can sell/support your GPLed product perfectly legally and make a good living from it while you starve.
Let's imagine a ridiculous scenario: someone takes Firefox, slaps their own logo/branding, maybe makes some minor code changes, maybe not and sells this product (source code is still freely available to this derivative product). This actually has happened before(citation needed).
The main difference between your tiny OS product and Mozilla one is that Mozilla has tons of social capital and anyone trying to charge something ridiculous for a Firefox clone would be laughed out of Internet.
For example, there were people selling various GPLed products on eBay and as long as source was included there was nothing illegal about it.
I tried to do the same thing with Hydra/Mjolnir[1], but failed miserably and burnt out completely. Hopefully I can work up the energy to finish my Mjolnir successor and sell it, but Bogdan[2] tells me it won't make any money.
[1]: http://mjolnir.io/
[2]: http://kapeli.com/dash
[1]: http://mjolnir.io/
[2]: http://kapeli.com/dash
I had no idea this existed, and I absolutely love Lua.
It's a different market: individuals vs businesses. If it takes a developer 10s longer to find documentation, zero shits are given. If the website can't accept orders because the queue keeps crashing, the company credit card is going for a walk to get the problem solved. A direct and measurable impact on the bottom line, and a visible effect to decision makers are two very nice properties of a good business.
Your product does look really nice, btw.
Your product does look really nice, btw.
I think the license here is important as well. I know of a few companies that just paid the $500 - $750 (it's changed over time) to Mike just to avoid even having to think about Sidekiq being some sort of GPL license. If it were MIT or BSD like many other Ruby gems, I'd imagine his revenue would have dropped precipitously. Given he called the license out specifically, he likely agrees.
It'll be interesting to see what his next project is and if it's a repeatable model. Asynchronous job queueing & processing is something a lot of Rubyists need and many on resque were frustrated. Sidekiq was a very attractive carrot, not the least of which because it was interoperable with resque, leading to a simple migration path. The stick was an unattractive license that was easily removed with a small fee.
It'll be interesting to see what his next project is and if it's a repeatable model. Asynchronous job queueing & processing is something a lot of Rubyists need and many on resque were frustrated. Sidekiq was a very attractive carrot, not the least of which because it was interoperable with resque, leading to a simple migration path. The stick was an unattractive license that was easily removed with a small fee.
From TFA:
"Divide the functionality into open source and commercial parts. Use a GNU license and a commercial license for the respective parts."
I really don't want to be That Guy, but this sentence takes us away from full-time open source. At least part time is spent working on source that's not open. "Open core" is the most common term for this hybrid strategy. I'm not going to get into the debate about whether that's a valid strategy, but it does make the headline misleading.
"Divide the functionality into open source and commercial parts. Use a GNU license and a commercial license for the respective parts."
I really don't want to be That Guy, but this sentence takes us away from full-time open source. At least part time is spent working on source that's not open. "Open core" is the most common term for this hybrid strategy. I'm not going to get into the debate about whether that's a valid strategy, but it does make the headline misleading.
Yeah, fully free would be something like selling GPL exceptions for the exact same product.
I really like selling exceptions. The product is available to everyone in its entirety without restriction, but the copyright holders are the only ones who can sell non-copyleft versions of it. Everyone else can still sell it under the terms of the GPL, like selling Debian CDs. It shifts the scarcity in a different direction, treats everyone fairly, and everyone who creates derivative works pays: either by giving back code or by paying for the privilege to not give back code.
Selling exceptions seems to me to be the right way to commercialise the actual product itself instead of support around that product. I know of FFTW and hg4j who do this now, and Qt used to do it. It's a good business model.
I really like selling exceptions. The product is available to everyone in its entirety without restriction, but the copyright holders are the only ones who can sell non-copyleft versions of it. Everyone else can still sell it under the terms of the GPL, like selling Debian CDs. It shifts the scarcity in a different direction, treats everyone fairly, and everyone who creates derivative works pays: either by giving back code or by paying for the privilege to not give back code.
Selling exceptions seems to me to be the right way to commercialise the actual product itself instead of support around that product. I know of FFTW and hg4j who do this now, and Qt used to do it. It's a good business model.
When the software is typically used for SAAS products and not "distributed" in the same way as something using eg Qt libraries the business case isn't as compelling however.
In that case, you sell AGPL exceptions.
Is there any really good documentation (book, article, series, etc.) on all the different models for this sort of thing, how they work, and it what situations they are appropriate?
http://en.wikipedia.org/wiki/Business_models_for_open-source... is a decent starting point.
Not that I've seen, but there should be. Maybe we can motivate some lawyers to put something together? :D
Yeah a "from the trenches" collaboration between some people who have taken different approaches and the lawyers who worked with them would be really valuable to me. (Hint: if anybody fits that description, I'm saying I'd pay good money for it!)
It is worth noting that this is also the opinion of RMS.
Do you have a reference for that? I thought he was against dual-licensing (i.e. selling a commercial license for your GPL code).
BTW I did this. It worked, but I stopped because some companies took months to pay: they already had the code. This wore me down.
BTW I did this. It worked, but I stopped because some companies took months to pay: they already had the code. This wore me down.
Btw, the GPL is a commercial license. I wish people would stop thinking that the opposite of GPL is commercial, otherwise businesses like Red Hat couldn't exist. The GPL explicitly allows selling the software. It just doesn't allow locking it down.
FTFGPL:
FTFGPL:
You may charge any price or no price for each copy that you
convey, and you may offer support or warranty protection for a
fee.You're right in this case. There have been a number of other cases where the whole software is open source (under a GPL or AGPL license) and the author sells a "non-viral" commercial license. Qt comes to mind as an example of this.
In this particular case, the author seems to be doing a hybrid. The original library is LGPL. If you buy the "Pro" version, you not only get the closed source bits but you also get a non-viral license for the open source bit.
The headline does indeed seem misleading though.
FWIW, I've been earning a living via open source software since late 2007 – I've just been doing it as a full-time employee at companies (SitePen, Mozilla and now Adobe).
In this particular case, the author seems to be doing a hybrid. The original library is LGPL. If you buy the "Pro" version, you not only get the closed source bits but you also get a non-viral license for the open source bit.
The headline does indeed seem misleading though.
FWIW, I've been earning a living via open source software since late 2007 – I've just been doing it as a full-time employee at companies (SitePen, Mozilla and now Adobe).
I think you're right. It's all about scarcity, ultimately:
http://journal.dedasys.com/2007/02/03/in-thrall-to-scarcity/
It can be very tricky to find something that's scarce enough with an open source project to make money at it.
In any event, I'm happy for him!
http://journal.dedasys.com/2007/02/03/in-thrall-to-scarcity/
It can be very tricky to find something that's scarce enough with an open source project to make money at it.
In any event, I'm happy for him!
I'd say you are correct.
How is this different from just having a commercial and non-commercial license? At least then people don't get locked out of features by not paying.
How is this different from just having a commercial and non-commercial license? At least then people don't get locked out of features by not paying.
Lets forge a path to FLOSS software, eh?
Hold on. So the money are made from a Pro version, which is not open source.
This is not "the path to full-time open source", that's how to use open source to bootstap sales of a separate commercial offering. Good to know, I'm happy for the guy and his 175K, but the title is misleading at best.
This is not "the path to full-time open source", that's how to use open source to bootstap sales of a separate commercial offering. Good to know, I'm happy for the guy and his 175K, but the title is misleading at best.
We make around 150k with our open source project too and there is no commercial license. Our revenue is from cloud and developer support. Maybe we should write a blog around that (https://erpnext.com)
Yes, that's the downside of making money with fully open source software - you have to find other means (support, hosting, ads...). But as an engineer - I really prefer to make money from selling the software itself - the thing I've created.
As far as I know, there is only 1 person in the Ruby world who is succeeding with this model, and this is Mike Perham.
While I admire his work and find his business model amazing, I think his advice is actually very, very shallow and is based on him being lucky, not on a proven business idea.
I'd love getting me proven wrong, though.
While I admire his work and find his business model amazing, I think his advice is actually very, very shallow and is based on him being lucky, not on a proven business idea.
I'd love getting me proven wrong, though.
Passenger is open source and has an enterprise tier. Though written in C++ they very much serve the Ruby world.
Nonetheless, I agree with your point that this model may not be suitable for every business.
Nonetheless, I agree with your point that this model may not be suitable for every business.
To be fair, there are probably any number of businesses failing to make proprietary products with Ruby and Rails at any given time.
But yeah, open source makes things a bit trickier, in my opinion.
But yeah, open source makes things a bit trickier, in my opinion.
Maybe it's rare in the Ruby world, but you don't have to look very far for other examples. It's basically the model Basho use for Riak, for instance.
Red Hat has a rather large number of GPL-licensed Ruby projects, does that count for you?
Travis-CI has a huge open source offering and started out of that.
Gitlab and Gitorious are open source and for profit as well.
Gitlab and Gitorious are open source and for profit as well.
I agree with all your points but I think he's trying to say, "... and you can ,too."
So the Sidekiq is a product that allows to implement service/daemon in Ruby? I am not a Rubyist, and couldn't figure out what this does ...
It's a product for handling background jobs, typically generated from web applications. It's similar in function to resque, delayed job, etc. Rails is bringing native background job support to Rails 4.2 in the form of Active Job[1], so these background job runners will become even more popular I imagine. Sidekiq itself provides a service/daemon (well, the processing part of it), it does not provide the ability to implement your own service/daemon.
[1] http://edgeguides.rubyonrails.org/active_job_basics.html
[1] http://edgeguides.rubyonrails.org/active_job_basics.html
Yeah, basically provides both sides of the common web application workflow of queuing longer-running and less-important functionality, often emails. It comes with a library used by application code to stick stuff on a queue in redis, and a daemon that pulls stuff off that queue and runs it.
Making money from open source software is a magic trick: it looks hand-wavey, but literally anyone can do it. The trick is that companies need support for products. Convince a company to use your product and then get them to pay for support and/or hosted service. They won't care if you open source it because they're paying you for support, not the product.
You don't have to go the Free/Pro model, but it makes companies feel better. Most people feel like they're getting a better product when they have a choice to pay more. Even if it's the exact same product.
I like to use Tibco Rendezvous as an example. There are very decent open source alternatives to Rendezvous, but people still pay boatloads of cash to use a proprietary, incompatible system. Why? Support. It just works, and if it doesn't work, i'm paying these jokers enough that they will make sure it works. I will not have to hire developers to make modifications or bug fixes, I will not have to figure out the upgrade path or maintenance myself, I will not have to even figure out the damn documentation. I pay money, somebody fixes my problems. Nobody gives a crap if the source code is available because the customer doesn't want source code, they want a working product.
(It also helps that business managers usually decide to pay for these things and not the developers using them)
You don't have to go the Free/Pro model, but it makes companies feel better. Most people feel like they're getting a better product when they have a choice to pay more. Even if it's the exact same product.
I like to use Tibco Rendezvous as an example. There are very decent open source alternatives to Rendezvous, but people still pay boatloads of cash to use a proprietary, incompatible system. Why? Support. It just works, and if it doesn't work, i'm paying these jokers enough that they will make sure it works. I will not have to hire developers to make modifications or bug fixes, I will not have to figure out the upgrade path or maintenance myself, I will not have to even figure out the damn documentation. I pay money, somebody fixes my problems. Nobody gives a crap if the source code is available because the customer doesn't want source code, they want a working product.
(It also helps that business managers usually decide to pay for these things and not the developers using them)
All the best to Mr Perham for his new project (which I guess won't be Ruby software), Sidekiq is a fantastic piece of software that addresses the needs of Actual People™ and does it in an efficient and streamlined way. That being said, it is true that the model is not as clear cut as the "Full-time Open Source" in the title would have you believe.
Which doesn't change the fact that there is an open source version of Sidekiq that works perfectly well, the Pro add-ons are most likely the only non-free parts and you don't necessarily need that to use Sidekiq.
Which doesn't change the fact that there is an open source version of Sidekiq that works perfectly well, the Pro add-ons are most likely the only non-free parts and you don't necessarily need that to use Sidekiq.
Author here. Thanks for the comments, all.
Yep, Pro is not open source. That said, 90% of my time is spent supporting Sidekiq OSS users, dealing with questions and issues so the OSS work is the majority of my time.
My next product coming out tomorrow is the same way: 90% of the functionality is in the free, OSS version and I would expect the same split in time.
Yep, Pro is not open source. That said, 90% of my time is spent supporting Sidekiq OSS users, dealing with questions and issues so the OSS work is the majority of my time.
My next product coming out tomorrow is the same way: 90% of the functionality is in the free, OSS version and I would expect the same split in time.
[deleted]
Babies, burnout, and budget cuts are lurking assassins for almost any open source project. Most developers do diddly-squat to ensure their projects can survive and grow, even for key bits of infrastructure we use every day. Mike Perham's built a piece of infrastructure for us Rails developers, and he's built a business to sustain it. I wish more developers would take on that responsibility.
[1] RailsApps: http://railsapps.github.io/