I think there are likely a variety of contractual options other than "24/7 phone support" which businesses would be happy to pay for, on an ongoing basis. For example, you could charge $500 plus $100 per year for "maintenance", and not be any more specific than "the software will be maintained in an ongoing fashion", and now you won't be starting from $0 next January 1st. As someone who has started from $0 every January 1st for the last 7 -- don't do it! It sucks!
Congrats, though -- Sidekiq is one of the few commercial OSS offerings that I know of doing well in the Ruby/Rails ecosystem. Most of the others just act as friendcatchers for consulting, too.
> charge $500 plus $100 per year for "maintenance", and not be any more specific than "the software will be maintained in an ongoing fashion"
I work at a mega corp, and I cannot echo this enough, we have tons of "maintenance" agreements for hardware and software of all sorts, $100 is not even in the noise level for some of these agreements! Software needs to be maintained, get this done upfront, it is a total pain in the but to have something fail, and then try and push through a purchase for "maintenance" after the fact. This means that I have to get a quote, get my boss to sign off, get purchasing in the loop, etc, etc. Just have this as an annual agreement and it will get processed like everything else. 10 years later, someone will ask, who uses this, and no one will know, and it will get renewed, just because they don't want something to fail ;)
Enterprise sales cycle is EXPENSIVE, so, while the actual cost of your service may be much less, you have to pay for the ten airplane flights and meetings and hotel rooms before you close your sale (and add a few one afterwards for good measure).
"Enterprise-focused VC’s sometimes refer to products priced between (roughly) $5k and $100K as falling in the “valley of death.” Above $100K, you might be able to make a profit given the cost of sales. Below $5k you might be able to market your product, hence have a very low cost of sales"
I'm not sure if all of that advice applies to a Ruby gem... big freaking enterprises don't use Ruby that much.
Does that point stands when people can freely start using the software, and enterprises decide to buy support because they are already using the product?
Somehow all that process must work for buying paper clips and pencils. Yeah, they buy those in huge amounts, but I can not conceive that they pay much of a premium. I know that governments have streamlined process for those situations. Don't corportations also have shorter procedures?
> big freaking enterprises don't use Ruby that much.
Of course not. Ruby is slow, dynamic, and uses a ton of magic. Ruby is inherently more suited to smaller developers, who can use it to generate code, run scripts, embed it in things, and make use of the magic to be productive (things like generating C++, Fortran, or HTML).
Firstly, I am not a huge fan of Ruby, but ruby isn't magic itself, just Rails, which is a piece of crap.
Secondly, 'big enterprises' tend to employ a lot of mediocre or poor developers, and as a result have gigantic code bases to do more poorly what might be done with 1/100th as much code. You say Ruby devs use 'magic' like code generation. Big Enterprises use copy and paste.
Also, in case you woke up from a coma, it's not 1997 and everyone generates HTML. What do you think 'big enterprises' do? Type the same header into 50 million pages?
Ruby itself may not be magic but it encourages magic frameworks which end up extremely hard to maintain under turnover. I guess part of the problem is that when you have a couple of smart developers they try to outdo each other in the cleverness of their code, so it essentially ends up being write-only software.
> Firstly, I am not a huge fan of Ruby, but ruby isn't magic itself, just Rails, which is a piece of crap.
I'll agree that Rails is crap, but Ruby most definitely isn't.
There's some interesting stuff going on in the Ruby world, mostly coming out of Japanese universities and research institutes. And Ruby certainly does have bits of magic, which is why it's so easy to write DSLs and code generators... Not saying other languages can't do it, but in Ruby everything is made pretty easy.
Unfortunately, support models only work for a limited set of software. It happens to work for Red Hat.
For a while, we tried making money off support contracts for Phusion Passenger. The amount of money we made with that put us far below minimum wage. It turns out that with Phusion Passenger, nobody needs good support. Some people may have trouble setting it up (mostly people who are not familiar with Unix, and don't have money for a support contract anyway) but for the vast majority of users, Phusion Passenger just works and never stops working. By making our software stable and user friendly, we were essentially shooting ourselves in the foot revenue-wise.
We didn't want to cripple Phusion Passenger to make more money off support, so we ended up selling Phusion Passenger Enterprise which only differentiates on features, not stability. This latter model turns out to be far more successful and has skyrocketed open source development to new highs.
For almost 20 years I've had this problem with "give away open source, sell the support," because I thought if it works well people don't need support.
I've learned a lot in those 20 years that made me realize that it's not that simple, but stories like yours make me keep coming back to it.
On the other hand, how hard have you tried to market support contracts?
We at Akvo couldn't do what we do if we just lived of support. We run the software as a service and charge money for it. We have some advantages that makes it possible to do this. But only support wouldn't work for us.
I noticed the really poor use of Internet systems in international development aid. More than $120 Bn is spent yearly on this, and nobody really has a clue where the money goes. There is no useful overview. So we started building tools to fix that and supply them as a paid for service.
Everything we build is open source software. We have 45+ people working on this, with paying partners such as the World Bank, UNICEF, Liberian government, Mars Chocolate and many hundreds more. It is not your ordinary business model, but it works and we are growing. You can make open source software and earn a decent living.
Wow. This is pretty inspiring. We at https://erpnext.com have been looking to help govt agencies implement our Open Source ERP, but lack a forum where we can connect with such needs. Can you suggest us a way forward. I think our product can serve a great need for government organizations.
You don't seem to do any custom development / extensions, which according to our experience¹ implementing OpenERP solutions, it's pretty much mandatory for any large company or governmental agency.
We initially burnt hands doing custom development so stay away these days. 90% of our revenue comes from cloud hosting, which is opposite of OpenERP (which gets 90% of revenue via Partners). If we do custom development, product will suffer, so we are staying out. But we are happy to consider it if it really makes sense.
Will be happy to hear your views though (will send you a separate mail on this).
Yes, we don't do any custom development at Akvo either. Our revenue comes from hosting, training and implementation consulting services, but not technical implementation services, but implementing the tools themselves within the organisation.
We avoid technical implementation services, as most organisations we work with have a really low internal technical knowledge. If we then take the responsibility for implementing the technical side, we find that they don't take the ownership of the bigger issues. These are things like learning to publish open data and the changes in culture which this implies in the organisation. Then their failure to embrace the change needed in the organisation is projected as our failure to implement the technical side.
We have technical account management, but require for our partners who implement our tools to either have in-house the required technical skills or hire in the required skills. If they don't do this we don't do the projects, as they are very likely to fail.
Thanks! I agree that your product has a huge market for government and other organisations. Our success comes out of a few core things:
- We brought together domain experts as equals, i.e. people working in international development, water and sanitation issues (our starting market), network organisations, computer software and services, computer software marketing and communications, to solve a problem.
- We say our team is a three legged stool. Partner team (more about that below), software team and communications team. If we don't treat all three equally the stool falls over. We go so far that we think it is imperative to not have an organisation run by the tech or the international development side, but by both sides. So we have until know had two directors of the organisation, one from each domain. Working very closely with the comms director.
- Maybe most importantly though, we have a very experienced partner team. They have worked in this market for decades. They know "everyone". We literally have connections to thousands of organisations through our networks and we understand how to talk to those organisations. Our partner team know where all the gremlins are and how the processes work. They know how to get the required startup and expansion investments as well as how to get the big organisations to use our tools.
About the partner team. We don't consider us having any customers. We treat all of the organisations that work with us as partners. They then treat us as partners too and it completely changes the relationship when you are trying to solve a problem. Of course it helps that we are a non-profit foundation. (We are also not-for-loss. We have a functional business model. This is critical.)
In a traditional company our partner team would consist of strategic sales people, account managers, project managers, consultants, trainers etc. We have a partner team that fulfils all those roles, but they are a _partner_ team. Sales are not done on a quota, no bonuses are paid (which often drive really crappy sales in a s/w company) etc.
We have no marketing and PR team. We have a communications team. Most of our staff communicate. Everyone is in fact encouraged and empowered to speak for the organisation. The communications team just supports everyone learning how to communicate well. We hardly do any PR. We may need to increase it, but it mostly does itself based on our peoples open communication.
I could write a lot more, but we are creating the Akvo Handbook, which will outline all of this, and be available under an open content license. You can read it all there then. But don't hesitate to ask any specific questions you may have.
Thanks for the awesome replies. They were really insightful - specially the idea to have an all round team to work on this. Surely some food for thought for a tech-only company like us. If you ever come across a need for accounting / inventory type solution, do keep us in mind, this would be something of interest.
I agree with the idea but not the don't be specific. The main thing I'd say about "maintenance agreements" is make it clear what they are and aren't getting.
Does it cover upgrades to work with new versions of another OS/framework/database whatever?
Does it cover new functionality?
Does it cover bug fixes? If so is there an SLA?
Is it limited in some way? X incidents? Y hours of your time?
There are such a range of these things that if you're not careful you end up with disappointed customers when it could easily have been avoided.
That's not to say it has to be comprehensive. Corporate organisations will pay a lot for a small amount of peace of mind, but make it clear.
My company has two good types of yearly contracts for "advanced support" oriented to large companies. In both we can charge a good price because they support complex technologies.
One is our own product that is very costly to maintain (reverse engineering third party applications) and some customers agree that they need to have this additional service.
Another one is for complex application virtualization. For example, we give the technology for virtualizing IE6 on Windows 7 and 8 but some Microsoft updates break the solution and the company needs to have an "insurance" against that.
Just wanted to say I love following your blog - And this is definitely something that's been engrained in my mind after reading it, and I'm glad you've reiterated here.
The title of this article is the opposite of what the article says.
He made almost no money with open source. He made tons of money by withholding features from the open source library and instead only offering them under a commercial license as an add-on. Since this is itself a violation of the LGPL, anyone using the Pro version isn't even using open source at all, as both the original and Pro enhancements are at that point licensed with a commercial license.
An accurate title would be:
"How to make $100K by writing an open source library, waiting for a lot of people to build a product using it, then holding back essential features until they pay you money, which they will do because they are suffering lock-in and it's way cheaper to pay you than pay a developer for dozens of hours of work to adopt an open source solution."
Something can be pay for use and open source. What he did here was totally fine. Sidkiq is amazing, and what it replaces is kludgy. If Sidkiq or Riak want to make a version that is specially geared for people that need software to scale then everybody wins.
The people at scale win because they buy the software for peanuts and they were able to do so only after hitting product-market fit. The people starting startups win, since they get well designed software from someone that has self-interest to keep it going.
I see no problem with this whatsoever. It isn't like the at-scale version of Sidekiq would ever have been built if it hadn't been for the cash. The only thing I would add would be that maybe he puts a sunset clause in there that auto-frees the source in a year or two. That way people won't waste time rebuilding the at-scale components.
There's nothing at all wrong with what he did - it's just not 'making money from open source' per se. I guess you can argue he would not have made money were it not for the open source project, but the actual money is coming from what he's holding back.
He tried selling support and failed miserably, he made no money. So, he issued a better version of the same software under a commercial license, and that sold well.
RedHat does not do that. Everything they do is available in CentOS, or is available freely. They make money selling support.
Redhat's strategy is a bit more complex than that:
They only support the official Redhat release, but that contains Redhat's trademarks, which you are not free to copy/modify/etc... and indeed, you have to pay for the official release.
I think it ends up being that if you need the official Redhat, you pretty much have to buy it, and buy a long-term-ish support contract.
In any event, support is not a public good along the lines of software: it's very much rivalrous and excludable.
In other words, redhat doesnt make money from open source. But nobody ever complains when they're held up as the poster child for how to make money from open source.
If a lot of people were able to build products based on his open source library, it seems wrong to claim that anything he held back was truly essential.
Sure, this is possible. However, this author is not violating it.
For example, if the regular version were issued with the Pro version merged into it, the author would have to provide an unmodified version in the same distribution lest he violate the LGPL. There isn't much consequence to this, unless he felt the need to sue himself.
However, since the author here also owns the rights to both the regular and Pro versions, he can just license both to the user under a commercial license when including the Pro version, which is what he does. At that point, neither is 'free as in speech' from the perspective of the person who bought the license, even though lots of the bits are the same. The user is using a non-free commercial license. The user could also use the free version under the LGPL, but that would be redundant, since they have the same code under a license they can use from buying the commercial license.
In this case the author says he relicenses both for users who can't use LGPL code.
No, this is wrong. The author's code is licensed to the author under a "license" that allows him to do whatever he wants, since he owns the copyright.
Just because he chooses to extend the LGPL to others doesn't mean he is himself bound by its constraints.
In the model you're proposing (where things have one and only one set of copyright terms that apply to everyone), how would things like Libreoffice be offered under multiple licenses simultaneously?
In which case, maybe it's classified as a derivative work of the original OS project? This is how WordPress tries to classify third-party themes and plugins, meaning they should "thus inherit the GPL license". See: http://www.wordpress.org/about/license/
Yes and it's standard for contributing to pretty much any open source project that's run by a company. The contributor's agreement you'll sign has you assign them full copyright for your patches, so they can do whatever they want, including make a non-GPL version.
First, the title is simply wrong. The OP did not make 100k with Open Source, he made 100k selling something that's an addon to his LGPL based offering. Another part of the package is a commercial license bundled with his software. Of course there is nothing wrong with that, but saying that he made money in os is just plain wrong, IMVHO.
>>In nine months of selling commercial licenses, I sold 33 for $1,650. If you figure I spent 300 hours building Sidekiq, that’s less than minimum wage. Result: failure.
Second, If the money was only reason why the OP build the software then I have to agree that this is a failure. If on the other hand sidekiq was used in some of this own projects, he should also calculate how much time/money he saved by creating it.
Why do you object to calling this 'making money with Open Source'? I agree that "making money by developing and selling closed source extensions to open source products" is 'making money with Open Source'. Especially considering he also developed and maintains the OS product.
Because it seems similar to claiming prostitutes make money by greeting people and chatting. Although they do greet and chat for free, what they actually do for money is different.
Note: I believe prostitution is a morally acceptable profession for consenting adults. Therefore I'm not choosing that analogy to be pejorative to the OP; I'm choosing it to be blunt. IMHO the OP is doing nothing wrong, and more power to him. I just agree with GP that the characterization of it as making money "from" open source is confusing.
Well for legal reasons, many of them do claim to charge money for the greeting and chatting, and whatever two consenting adults happen to do after that is their own business.
It's true that they probably couldn't charge for the greet and chat if it weren't for what they do for "free." It's also true that Mike Perham probably couldn't charge for his commercial work, if not for what he did for free.
That analogy would be correct if there would be many, even a majority, of clients that were indeed interested in being greeted and chatting and would seek out the prostitute to obtain that free service only a daily basis. At the same time there would be other clients that were interested in, and would pay for, additional services.
Most of the money made was made with the Pro version of the software. Correct me if I'm wrong, but that version has a commercial license, not an open source one. He's making money with a commercial addon.
Charging a flat rate ($500) per company is leaving a lot of cash on the table. Have you considered a tiered model based on number of servers in use?
As well as increasing fees from Megacorps, the flipside is you could also offer discounts to non-profits, early startups, and so on, and in exchange for links on their homepage.
The authors article is good although it misses a tiny little detail when calculating hourly costs. Its not just his $100K/700 hours = pretty good, its also his customers thinking, hmm, it took a specialist 700 hours, so it going to take our busy guys 1000 hours part time, and our guys are already busy, and he's only asking $500, thats a bargain at 50 cents per hour to replicate...
Now if you start demanding $5/hr from each customer then the outsources in India are going to start eating into your sales when they take the work inside or just figure out a work around that doesn't take 1000 or 700 hours.
Another interesting issue is signing budgets. I have no use for this particular example but my boss can sign off on $500 at pretty much any mega corp I've worked at, but if you demand annual auto-renewal ongoing charges or get into the mid 4 figures suddenly you have to convince a heck of a lot more people than me and my boss. If you're charging more than a conference or a training class, or you're demanding annual payment, its going to be a harder sell for megacorps. Sure the code monkey and his boss might love it, but now you need to convince additional bean counters who think ruby is a precious stone and its all downhill from there. You could try to corporate speak market it to get past the bean counters with lots of babble about proactively leveraging the synergy of the enterprise cloud platform but that risks repelling the code monkey and his boss, a fine line to walk.
Really impressed by how customer-friendly the licensing is:
> How many licenses do I need to buy?
> Every organization that runs Sidekiq Pro for their own benefit must purchase a license.
> GitHub runs *.github.com. They need one license for their entire site.
> GitHub sells GitHub Enterprise to various customers. They need one license per customer because the product is installed and run locally by the customer.
> Pivotal Labs builds websites on behalf of customers. They need one license per customer because the customer is the one getting the benefit of Sidekiq.
If your story is true, then stop talking about it already!
First,
Since you're in the U.S.A., you'll be getting into the 40-50% marginal tax bracket with federal, state, and Self-Employment Taxes. If you incorporated in an off-shore jurisdiction, you'll keep all your money. In your situation, it's completely invisible to your corporate customers where you are located. If they're willing to pay random guy in Portland, Oregon, they'll pay random company in Singapore (for example). You could even disclose the existence of the foreign company to the tax authorities. In that case, don't draw a salary or a dividend from the foreign company, and you'll still pay no U.S. tax. Let the company pay for your "business travel", "business expenses", etc. And otherwise just let the cash pile up in the foreign account.
Second,
I highly doubt you'll gain additional customers through your blog. It sounds like you get customers because they are already using the open source component, and discover they could benefit from the paid component. Your article about the $100k gets you hacker cred, but also draws competition. Blog about the open source component, and keep mum about the dough.
The IRS has already thought about this scheme. If you are a US citizen, you need to report all foreign bank accounts if the sum of foreign money is over $10k. Failure to do so is a $100k fine. I expect there are other problems here.
I had heard that you could license your software to your company, which is advantageous since apparently license fees are taxed at capital gains rates (15%). I have not verified this, however.
I upvoted you because it's an interesting dissenting opinion, and I've always wondered about whether the upside of being open beats the downside of additional competition.
We also don't know whether he paid taxes on the income (I also guess not), and, most importantly, whether his blog post will bring him additional revenue.
Do you have many examples where blogging about success brought about competition? Are there big barriers of entry to building what he built? It looks like you'd need at least 700 of developer hours, I wouldn't do it lightly.
OTOH if I had found an easy way to beat the lottery I wouldn't blog about it :P
>> We also don't know whether he paid taxes on the income (I also guess not)
Mike is an upstanding citizen and member of the open source community. There's absolutely no reason to make unfounded claims like this against his integrity.
Author here, thanks for the kind words. Always nice to wake up to a DDoS of my site at 2AM. :-)
Recurring revenue is a pricing change I'm seriously considering, I just don't have a payment system in place that can manage my customer list and handle the annual CC charge.
"Making Money in Open Source" can have several meanings. Selling software is just what most people think of when reading the title. I myself can say I made about $150k in Open Source this year. But it wasn't by selling software, it was by doing freelance jobs and consulting that involved free software only. Money wasn't coming in on autopilot, I had to get up every day and go to work at several places. But for me, free software is the reason I live a very comfortable life, doing things I love to do. It just isn't selling software, but everything else around it. I always tell my friends that I am the perfect example that Open Source brings in more than enough money.
I can't figure out how the license on the software is relevant to this story. It seems like you could just as easily tell this story to relate how well a lucky money-making charm works. The charm did not make you money; the hours you put in consulting did. I mean, this doesn't give me any reason to open-source any software I write outside of a specific contract to do so.
Having a large picture of someone's face staring at me next to the text distracts me, creeps me out, and makes it very difficult for me to read. Lots of tech blogs have this anti-feature but this one is particularly egregious.
I don't know such a source but you may be able to find some after some research. Like Spree is an open source product but the company behind it employs developers to work on the product.
I really wish someone would do a PhD dissertation on it, or write a book on it, or something. I guess it's likely that there's something somewhat like what I'm looking for out there already.
So who provides support for the base product? My concern with the free and 'enterprise' version of products, is support for the free.
You could say just community support, but then if things aren't getting fixed either you end up fixing them or your product gets a bad name. If you provide email support, you're tying a lot of your time to the free product.
I'm a big fan of Sidekiq, and the model he's chosen. Some of the features implemented in the free version (retries with logarithmic logic as to timing, scheduled tasks) could possibly in a paid version, and the price point for the Pro version ($500) is a bit bold.
Big thanks to the author for posting this, and for including some actual numbers!
This is also exciting because it shows that you can make money directly with an open source product, instead of making money with services surrounding a product.
Can someone help me understand whether he's the only one allowed to build a paid service over the open source code, or could anyone technically take away all his open source code and build the same service he provides in the pro.
Because if he doesn't have that control, then this is really not making money with open source but rather relying on existing open source to make money
As a non owner of the copyright, but beneficiary of a GPL license, you would be allowed to make a derived work (your own "pro" version), and to distribute it (to sell it), but it would have to be under the GPL.
In this case, since it is a library under the LGPL, you could make a client product using this library, instead of a derived work, and you could distribute this product under your own terms, but if you provide the library along, you must of course keep this library under the LGPL (and provide the sources of the library).
So with the LGPL, you are free to make competiting proprietary products.
It's encouraging to hear this can work. Of course that guy was extremely fortunate to be making something everyone was interested in, so it's still a risk (but then again: what isn't?).
There was no fortune to it, it was years of OSS work on lots of Ruby projects followed by a realization that existing solutions were terrible and I had the knowledge to make something better. Nothing like years of experience to put you in the right place at the right time.
You say fortunate, I say foresighted. In any event. I imagine that he started building it to meet his own needs and the growth of revenue now is a happy side-effect.
It's probably always a bit of both, but I'd say that level of success doesn't come without the necessary context (several things have to conspire for it to happen). Anyway, it's an inspiring story!
Congrats, though -- Sidekiq is one of the few commercial OSS offerings that I know of doing well in the Ruby/Rails ecosystem. Most of the others just act as friendcatchers for consulting, too.