"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.
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.
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?
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!)
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:
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).
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)
I can report I'm earning a living (in San Francisco, no less) by working on an open source project, RailsApps [1], which is starter applications and a tool (Rails Composer) that generates starter applications. The business model is different from Mike's. Developers support the project by purchasing a monthly subscription at $19/mo. As an incentive to support the project, I write in-depth tutorials about Rails, which only the subscribers get. Some people subscribe because they want to keep the project going, and others subscribe just to get the tutorials. Either way, it's over 500 subscribers right now. I'm not sure how many other open source projects could use this business model (maybe you need to be a writer as well as a developer) but it's a route to consider if you want to make a living doing open source. And I'd say we definitely need more ways to sustain open source projects.
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.
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?
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.
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.
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.
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.
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.
Please do; as noted above, lots of us would be interested in hearing the various stories of how groups have monetized open source successfully (and even unsuccessfully).
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.
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.
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.
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.
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.
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.
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.
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.
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.
"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.