Ask Slashdot: What's the Best Business Model for An Open Source Developer?

An anonymous reader writes: I'm interested in creating really good open source software. However, unless programmers have an incentive to work on their projects for long periods, many projects are be abandoned.

There's many business models surrounding free/libre open source software: support (pay for help, or additional features), premium (pay for more advanced software), hosting (pay for using the software on someone else's servers), donation (two versions of the same app, pay because you want to be nice to the developers), etc. Not all of those business models align the interests of the developer and the customer/user in the same way: support-based models for example, benefit developers who introduce certain mistakes or delay introducing features. (In the short term. In the long run, it opens a door for competitors...) Which of those align the interests of both?
The original submission also asks if any of these models are "morally questionable" -- and if there's other business models that have proven successful for open source software. Leave your best thoughts in the comments. What's the best business model for an open source developer?

Comments

Not only that the question is wrong

[Anonymous Coward]

"Pay for help" = bone-headed.

Support is the most expensive thing there is. That is why companies outsource it to call centers in India.

"Pay for additional features" = bone-headed

Just wait until you get an idea of what a customer is going to want for a feature! 4 out of 5 are likely to be nearly impossible.

"I'm interested in creating really good open source software" = triple bone-headed

Why not just say "I wish to live a life of poverty and donate my bones to the Church"?

If you have skills and ambitions, you deserved to be paid for it. And if you don't, it isn't really going to matter what choices you make.

But the first three rules of business are: cash flow, cash flow and cash flow.

Personal experience as someone willing to pay

[argumentsockpuppet]

The company I worked for was starting to look for a replacement for Lynx, and I was in the position to choose OpenFire. I wanted to find a host, someone that would offer configuration services and a host for it. I reached out to the various listed supporting companies at the time and got nowhere. I would have been happy to pay someone for a dozen hours worth of configuration support. Instead I ended up setting it up and working through all the issues myself, but that was my least preferred option. There would have potential for ongoing reconfiguration assistance. Eventually we switched back to Office 365's (renamed) Lynx system. That's thousands of dollars I would have been happy to redirect to an open source support company if I'd been able to find one.

If there's a lesson to be learned there, it's that there is money to be had if you can find the demand.

What software you develop will determine what service you can offer for it. What I want to see more of is:

• * Open source software for free
• * Configuration support for a fee
• * A hosted server with support as a service.

The business model depends

[hey!]

on the nature of your customer and the type of software. When you talk about 'business models', before you get into any kind of complicated strategy, the important thing to fix in your mind is that you have to answer this question: where is the cash going to come from?

Let's say your software is a version of Tetris. In that case you don't have many places to get cash from. What you'd do is to find sources of revenue that were so small that it really isn't worthy anyone's time to download the source code from github and build it themselves. Put it in the app store and charge $0.99, or throw up an occasional ad. Just avoid being too greedy, and people will be OK with the bargain. And make sure the app is relatively bug-free, because people will simply stop using it if it frustrates them and there goes your ad revenue.

Tetris represents one end of the spectrum along several dimensions: it is simple in concept and use; it is as non-critical as any app can be. Now I spent a decade as a lead developer in a small company with a product that was the exact opposite ends of the spectra. It was highly complex, took training to operate and administer; had many, many components to install and configure, and was mission critical. This software happened to be proprietary (not my choice, at the time many of our customers had "no open source" policies, strange as that may sound), but the practicalities from the customer perspective would have been the same either way.

License fees were only a tiny fraction of our revenues; in order of size our revenue streams were (write this down): day-to-day technical support, on-site installation and training, software customizations, hardware sales, license fees (in a distant fifth), and finally advanced training. From a revenue standpoint we probably might as well have been open source. There is one thing that being proprietary protected us from: competition. You will have to consider the question of why your customers will turn to you when they could in theory turn to anyone. Competition from other developers is the single biggest problem for any open source business model.

So on either end of the complexity or mission-criticality scale, to make money with open source you've got to be the most convenient way of getting things done. For simple apps, keep them cheap and reliable. For complex apps, you have to sell yourself, and that means being pleasant and professional. If you build a team, don't fill it entirely with grouchy genius slobs; make sure you have people on the team who are young, attractive, and personable too. If you've never tried it, you'll be amazed. If it's just you, well you might not have much to work with, but you should spruce yourself up a bit. Maybe not a suit -- customers will see that as phony if you're not the type -- but maybe throwing a blazer over your jeans and t- shirt will hit the right note.

As for technology, if you have invested a lot of your life in developing a product you'll want to avoid becoming commodity (i.e., easily replaceable) labor after it's finished. That means you need to select your platforms carefully. Avoid the latest "golden hammers" that everyone's learning. Instead look for good projects that make your job easy and have enough of a user base that support won't go away overnight. Think "Scala" rather than "Node.js". Again -- this is from the developer's standpoint. If you're a customer paying someone to develop a system that you will open source, think "Node.js" rather than "Scala".