How to make $100k in Open Source by working hard
mikeperham.com
mikeperham.com
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.
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 ;)
http://www.joelonsoftware.com/articles/CamelsandRubberDuckie...
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).
also
http://cdixon.org/2010/02/06/selling-to-enterprises/
"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.
That said, it's a great success story :)
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?
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.
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?
But others don't, the one I work for has a generic process for software/development tools, which must be budgeted for one year in advance.
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.
¹ http://www.thinkopensolutions.com/SoluçõesOpenERP/CasosdeSuc... (Portuguese)
Will be happy to hear your views though (will send you a separate mail on this).
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.
- 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.
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.
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?
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.
If anyone would like to follow him - here's a link to an arbitrary archived newsletter that he's published where you can sign up: https://training.kalzumeus.com/newsletters/archive/sources_o...
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.
Simple support gives a lot of headache.
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.
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."
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.
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.
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.
It's pretty obviously not a valid analogy.
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.
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 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.
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.
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.
Admittedly this is a rather loose analogy.
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.
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.
> 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.
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.
Good luck.
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
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.
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.
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.
No scarcity, no money, it seems: http://journal.dedasys.com/2007/02/03/in-thrall-to-scarcity
Install them a open source Webserver with enough power for $100K ;-)
Clearly there is a massive open source economy. I would like to understand that better.
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.
Just curious how others handle this.
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.
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.
http://www.mikeperham.com.nyud.net/2013/10/01/how-to-make-10...