GPL business models for a small company/shop/startup

Question

Note: I don't have any awesome project that I'm intending to monetize, this is just something I'm thinking about

What models are there for making profit from developing GPLed software?

I've read around a bit and I realize that:

• You can charge whatever fee you want for distributing it
• When someone buys it from you, he can also (re)distribute it for whatever fee he wants, he can even distribute it free of charge.

So, you can sell your software, but even so, it doesn't help much because if it's really good and people want it, it will soon be posted on other websites for free download.

Have you seen any successful model for selling GPL software? If so, please enlighten me/us.

Any ideas you've thought of? If so, share your thoughts.

I'm not talking about a huge company (e.g. Redhat), but rather a small company with a single or very few developers. However, I'm still interested in reading (in some detail) about how these big players do their business.

P.S. If you're not sure what I'm talking about, please read Selling Free Software.

---

I'm making this a community wiki because it's very subjective an open ended.

Answer 1

One way to profit off open-source software is for companies to release open-source software, and then sell support for it or modifications another company wants made to it.

Answer 2

Someone just asked a question pretty similar to yours: http://stackoverflow.com/questions/114765/open-source-balancing-altruism-and-making-a-wage

Answer 3

You can certainly sell compiled binaries.
If the app is a dev tool on Linux then all your customers will build from source but if it's a desktop tool for organising photos on Windows or a Mac Photoshop plugin then many of your customers will pay $20 for a simple installation.

If you write it then you can also sell it under any license you want - however you will have to get any other contributors to agree to this.

Answer 4

You can't really be a "product" company and expect to also be able to GPL that software. It sounds like you might be asking "How can I both sell and give away my software?".

The "Redhat model" of selling support for a free product is a popular one that might work. Especially if you're selling customized software -- you could open source the base, but sell customized versions to customers.

There's also the Xchat model: Sell binaries for windows. Give away the source. This doesn't entirely work because then everybody just ends up using 3rd party builds of the source.

I think,however, most companies that work on open source products are not selling that software at all. You're working on open source software because you need that software to be good to achieve some business that isn't directly related to said software. Google isn't in the business of selling web servers, but they certainly need the software. This is a market where you'd traditionally pay a vendor instead of just doing it yourself with open source.

While Free (in the RMS sense) software may be a fantastic thing, you have to consider if what you want to do is really compatible with the ideology of the Free Software movement.

I don't think anything less vague than what I've said here is possible without knowing in more detail what you want to do.

Answer 5

If your business model is not selling software-as-a-shrink-wrapped-product, you will find other business models that work and the software is merely a catalyst. Otherwise, don't bother.

Like several others have mentioned, the services model seems to have proven itself to be largely usable. This services model can extend from servicing your software product, to actually servicing a real world problem. Your software helps (catalyst) the problem but still requires you to actually work it for the specific problem.

Also, you could do an Apple, where your business is actually selling hardware. This is particularly useful in the embedded space. In that case, your software is only there to make the hardware easy to use (catalyst). Clones don't bother you as long as you move boxes/boards/chips.

Finally, in the spirit of Web 2.0, your business could be selling content. In which case, your software is just a way of attracting people to your site (catalyst) to view actual content. Maybe it's easier to use or delivers the content in an amazingly different fashion.

The point is that, you need to get your head around the software-is-a-shrink-wrapped-product business.

Answer 6

Another option is to sell development enhancements ON the open source projects.

• Select one or a handful of well known, widely used projects that have practically unlimited scope for growth. Some good examples of this are turn-key business products or web app frameworks. Prefer ones that you and your team members are already familiar with.
• Identify business that are using these tools, or are likely to benefit from using them.
• Determine what enhancements to those tools would give those businesses a competitive lead, and the difficulty of making those improvements.
• Offer to deploy the enhanced version for a price that corresponds with the cost of the above steps.

There are a few key points to this. First, you are charging for the actual work you do, of developing a product and deploying it for your client, not for copies of an already completed work. This has an enormous tendency to mitigate the risks of taking on a software development project.

Second, until you transfer the product, you are not obligated to share your improvements. This has a key benefit to your client. The improvements are made to suit the clients exact business needs, and since the improved product won't be widely available until the client has already deployed it, they will get a substantial lead.

On top of that, under certain licenses (including the GPL) if the product is for the client's in-house use, the client need not share it at all. You might choose, if you wish, to share the improved version at a later date, say 6 months after the client has already received substantial benefit from the improved product.

Answer 7

Your approach possibly depends on what exactly your product is. Qt is an excellent example of this; Trolltech had made quite a nice bit of money out of it (until they got bought by Nokia, who seem to have other plans for it). That only really works for libraries and similar where the "derived works" thing applies to your customer though - it obviously wouldn't work in most cases where the user doesn't care about making any sort of derived work based on it.

For those not familiar with it, Trolltech wrote a cross-platform C++ application library called Qt, which is generally regarded as being pretty good. Qt was dual licensed under the GPL and a proprietary license of Trolltech's. Basically if you wanted to use it you could do so for free, but had to GPL your product; alternatively you could pay Trolltech a licensing fee and get it under different terms which didn't affect the licensing of your product. IMO that was a neat solution to them releasing Free software but also maintaining a solid income.

Answer 8

I don't have experience myself, but the model I have seen is double licensing for proprietary products. Let's say you are in a very niche market, with a very good library/product, which is under the GPL. Proprietary vendors cannot legally use your library, so you have a double license which is proprietary, for the same code. SRC is such example

One of the big drawback is that you must own all the code being double licensed (you can't double license code which is not your own without the agreement of the other developer), which can get tricky.