Making Money With Open Code, APIs, And Docs?

frustrated-open-sourcer asks: "We have a product in development and we want to make the APIs, docs, and source public, which is what we've announced, but we have to be able to make money on the end results or we'll just abandon the project. Is there any other way but to be closed or use patents?" I've had a lot of folks ask this question, but this one is by far the best version I've heard, and raises some really good questions.

"We've looked at the common model right now which is to sell support and give the code away on a CD for lots-o-money like a record label does. But our product doesn't work with that model very well. Our product is not many megabytes, so a CD to move bits isn't really justified. It's also fully documented in HTML, with man pages and HTML for the API, so a dead-tree manual is not needed at all. We're also doing development in a CMM-3+ environment, so there is no need for someone to buy support unless we purposely start adding "features" (i.e. bugs) or make it so complex no one can use it without calling us on the phone. That's just not an acceptable option since our product needs to operate in a five-9's environment, where if it doesn't work right it's never even allowed in the building.

We realize that if we do keep the source closed, but open the API or docs, someone will clone it because they don't want to pay for our work. Even with the typical no-quality clone, this makes the product life too short and the market too small to justify the large development costs.

Since the above model doesn't work for us, the only other way to make money (other then a sweet stock market scam) is to have a pile of patents. This is definitely not the way we want to go since we would need five lawyers for every geek in the company, and we all know software patents are all bogus since everything was done by 1975.

So did we back ourselves into a corner where we have to move to closed source or patents? Or should we just give up and go back to the day job working for someone with a pile of patents and a closed everything that can pay us? There are alot of issues here, but the bottom line is the bottom line, we have bills to pay, and if we can't pay them we'll go back to doing something else.

- frustrated."

Comments

Why open source?

[grahamsz]

I mean I realise the open source community is fantastic but there is still no requirement for companies to open source things.

At the end of the day, i'd guess, your company is in business to make money and I dont entirely see why you should be so keen to open source something if your livelyhoods depend on it.

Where open source fit in nicely is when a company has some internal software that they use and isn't central to their line of business. This way they can return something to the community and other people can help them sort out bugs.

Obviously open sourcing some of your products can help promote other products, but this essentially only works for large companies who aren't dependant on one core product.

If you have developed a package which is truly unique then you could potentially make a lot of money off it, and I think that's only fair. But unless opensource fits in well with your business proposal then there's no real reason to use it (apart from that warm fuzzy feeling inside)

Ok having stuck my head up and i'm going to hide before someone shoots it off :)

benefit analysis

[streetlawyer]

What benefit do you hope to get from opening it up?

Do you want it to be debugged by the (purely hypothetical) "millions of eyes" of open source coders out there? No, you've already said that if it doesn't work first time, it's fucked.

Do you want the open sourcies to be involved in developing it going forward, and extending the program? If so, then consider a restrictive licence which puts it in the public domain, but with limited rights. Anyone who really wants to be involved in extending your product will still want to be involved (if it's good); as for the rest, fuck 'em.

Or do you want the deep satisfying feeling of being "part of the free software community", and "knowing that you Get It About Open Source"? Then go ahead, open it all up. But realise that this will probably be a costly luxury.

Or indeed, have you not thought about this in any very great depth yet? In which case, now might be a good time to start.

Oh yeh, and whatever you choose, software patents are almost certainly not going to help.

five nines ? Support!

[frost22]

Hi,

We realize that if we do keep the source closed, but open the API or docs, someone will clone it because they don't want to pay for our work.

Let me start with something obvious: there is no legal way to seprate somebody from his money who doesn't want to be seperated from it after having judged the alternatives.
If a potential customer of yours sees more value in reimplementing your stuff than buying it from you then you have priced yourself out of that particular market anyway. So the debate is moot.

As usual in business life, offer something of value to the customer he is willing to pay for.

"We've looked at the common model right now which is to sell support and give the code away [...] since our product needs to operate in a five-9's environment, where if it doesn't work right it's never even allowed in the building.

I work in a five-9s environment. This is the perfect place for high-end support contracts. Of course no 'we will help you on the phone if you happen to get us on a free line' type of support, but a 'yes sir, we will be on site within 30 minutes 7 days a week 24 hours a day and make it work again' type of support. Priced, of course, accordingly.

90 percent of the support contracts of this kind are cover-my-ass contracts anyway, but in a five-9s environment you practically have to have these.

f.

Support Contracts are not Evil

[The Famous Brett Wat]

Without knowing the specifics of your case (how small the market, etc), it's a bit difficult to give a detailed answer, but probably the most important thing to realise about software is the following.

In my experience, most companies who are putting software into a mission-critical situation would prefer to pay for their software than have it for free. And what they perceive they are getting for their money is not the software itself, but rather a committment from the seller that the software will be supported. Your software doesn't have to be unreliable in order to justify a support contract; nor does it have to be heavily burdened with various flavours of intellectual property rights in order to persuade companies to part with large wads of dosh in exchange for it.

My suggestion would be to not make a big deal of the software license terms. Put it under a GPL or BSD style license, or even in the public domain, but just don't make a selling point out of it. Those who are interested enough to care will ask and be happy with the answer.

Make it available for download on a website, since it will be too small to justify the pricey-CD thing, but dress it up a bit like an evaluation copy -- probably best done by making it say "THIS IS AN UNSUPPORTED EVALUATION COPY", but it depends on the specifics of the case. Remember: the suits want to buy your committment, not your software! Do have a CD, though: make it part of your support contract, just so they have something physical and professional-looking to put on a shelf. Heck, if it's a small market, you can customise it by changing the "unsupported" message to indicate their name and the fact that you are supporting them. Such a comforting reminder! :-)

The benefits of this approach are many. One is that you can skimp on lawyers. You'll still need them for your support contract terms, for example. [Reminder to those who aren't catching on: support contract does not mean unreliable software; indeed, the ideal case is where you sell a support contract and never have a call from the customer because the software just works all the time. You think they'd be unhappy with paying for that level of service?] The customer is also happy because they don't have to count licenses or install dongles or do other obnoxious things associated with restrictive licensing. You can review their support contract service level agreement at regular intervals based on their usage, however.

Once you've got some suits paying you for your support, you should then aim to delight them with your responsiveness to their questions. You might want to hire a suitably talented monkey to handle the trivial stuff, but always be available to address the concerns of those you are being paid to support. Most proprietary houses set such dreadful standards of support that they shouldn't be hard to outdo. So long as they feel you are always poised and ready to answer your email or phone calls, they'll be happy and keep forking out the support contract fees.

Of course, there's the other class of people: the ones that don't pay. They are your friends too. Anyone with a clue who is using your software and providing you with bug reports is an ally. Be responsive to people who aren't paying you but who are doing you a great service by reporting real bugs, or simply providing ongoing testing (particularly for new releases). People without a clue who can't get it to work can be foisted off on some "users" mailing list or newsgroup: nobody should expect Linus to help them install their kernel.

I could go on, but I think by now you can see the pattern that is emerging, and decide whether it is appropriate to your situation.