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 :)

Open source not good for small companies

[Jon Erikson]

As a consultant that has worked in the industry for some years now, I can say that your situation is not unique and all, and that there are quite a few companies in the same boat as you.

Whilst excersing my new-found elite Linux skills using my Corel Linux box at home I have found an essay by someone called Eric S Ramond called "The Cathedral in the Bazaar" about the values of open source vs. closed source. An interesting read, if a bit naive, but it misses out one important point - people need money to live, and if their job is programming, they need to make money from doing that.

Now the technical benefits of open source may be apparent, but the philosophical baggage that it brings with it means that do develop an open source product at work, you need to either a) generate revenue through secondary services such as support or b) be part of a large company that can support the monetary loss.

This seems to me to be an unfortunate side-effect of the GNU Public License, and it means that the smaller players in the commercial sector will be unable to move to the open source model for financial reasons. Maybe a new licensing scheme is needed?

---
Jon E. Erikson

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.

Hard Topic to Resolve

[hattig]

Giving the source code away is fine, if they have paid for it. Just don't allow the end people to redistribute the software you sell them, i.e., don't put a clause in the license that allows them to pass on the code, like the GPL allows. So you will be selling a product still, but the product will include the source, APIs and docs. You don't have to give them away to everybody you know. Even the GPL only states that you have to provide the source code to the person who has the binary, if they don't have the source.

Giving the code away is a good move in many aspect, it is good for marketing, and it is going with the current bandwagon. If your product is not that hard to replicate though, then it isn't worth much anyway - there is nothing terribly unique about it. Patents can be used to resolve certain IP issues - and they should be used if the IP is new, original and non-obvious. Of course, being a software only solution, you can only get the patent in America, which limits the power of the patent. You could give a free license for all free software, to avoid being badmouthed about it, but software patents are not desirable, as you point out.

Make the product a solution. Corporate entities buy solutions - basically products that solve one particular thing very well. The support for a solution will be there, and you can make money from selling the product as a solution. Many companies will also like the fact that they get the source, not the majority of companies, as it will mean nothing to them, but some. These companies will like the power to amend small things in the codebase to meet their needs.

Otherwise, you are hitting the nail on the head. What incentive is their to write easy, good quality software when you are trying to make money from support? Luckily most computer users aren't that clued up, and will need support whatever the software or hardware(Moving the Mouse for Dummies! etc).

It just depends on the target audience for the product, which you haven't specified, so it makes it hard to assess your chances. I wish you luck.

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.

This project remains half-baked

[streetlawyer]

You are thinking about this altogether too late. You've written the code, and done the documentation, so the product's complete, right? Wrong. A software product contains three equally important elements; code, documentation and license. The license is arguably the most important part, because it drives the profitability and economics of the whole shebang. But of course, code-monkeys always forget this because in their minds, they're back in Podunk U. CS grad school, and they don't want to deal with "suits" (strange isn't it how the whole "don't judge us on the way we look" geek crowd identify themselves by hating people for the way they dress).

Now this is important, so I'm gonna repeat it twice, with increasing emphasis:

If the legal work is not finished, the project is not finished

If the legal work is not finished, the project is not finished

If the legal work is not finished, the project is not finished

You screwed up badly by your own admission, by not getting good legal staff incorporated into the development plan. Now you're trying to rescue the whole deal. All I can reccommend is, hire a lawyer. And don't try to cut corners, because you've clearly developed the whole thin in this lop-sided fashion.

Re:This project remains half-baked

[anonymous cowerd]

Surely, JSM, you will have permitted me to hate Herr Hitler way back at the original publication date of Mein Kampf rather than withholding judgment until he began to transform those lurid thoughts of his into concrete actions.

(Don't you dare give me that "Godwin's law" crap. I won't put up with it; it censors out discussion of mid-twentieth-century history and politics unconditionally.)

At any rate, the true reason "geeks" hate "suits" is because whenever unopposed, "suits" eventually start to insist that the "geeks" must dress themselves in "suit-wear," to be specific, neckties. And neckties are evil. They strangle your respiration, they appreciably choke off the vital circulation of arterial blood to the oxygen-hungry brain, and insensibly but surely they misalign one's delicate neck vertebrae. You all legal hotshots and rich execs can afford weekly therapy at chiropractors or massage parlors, but the rest of us, if we do not vigorously resist the abomination of neckties, eventually end up hopping crawling and limping like Igor, decerebrated to the tragic point where all we are capable of is watching TV.

A fate worse than death, I tell you! Burn those neckties, burn them all! If the "suits" refuse to take theirs off, no matter, burn them as well! You tight-squeezed and breathless ladies are welcome to throw off your garments of oppression and fling your brassieres into the bonfire as well.

Yours WD "hack in the nude" K - WKiernan@concentric.net

Why we switched to Open Source

[Simon Brooke]

My company develops data driven, web delivered applications mainly for corporate intranets. Our products are based on an in-house Servlet toolkit, Jacquard. The board paper I prepared which lead to us putting Jaquard Open Source (actually BSD licence) is here.

Brief summary of the argument: our customers are not the people who buy toolkits and components, they're people who buy completed applications. But in order to deliver completed applications we need a toolkit to build on. If we try to keep our toolkit proprietary, it will fall behind competing toolkits (such as, e.g., Enhydra) because we don't have, inside the team, enough people to develop it and debug it fast enough.

We could adopt another toolkit (such as Enhydra) but if we do we become just another user of the toolkit, with little control over its direction and no particular reason for people who want things built with it to come to us. By being the core of an Open Source project we get potential for kudos, the ability to steer the project, and, hopefully, a wider user base for the toolkit contributing patches and extensions.

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.

Use a time-delayed open source licence

[cabalamat]

You could sell the software with a non open source licence but with a provision that it becomes open source under the GPL after a time delay of say 3 years.

The product you sell could include the source code under a disclosed source licence (but a user would still need to pay your company to use the product). Furthermore, you could permit registered users of your product to develop modifications and send each other patch files, as long as you are permitted to put the patches in your future releases.

Re:Obviously you are not a GPL expert

[anatoli]

Nice FUD (or else your lawyers are incompetent, to put it mildly). Compiler output is not a derivative work of the compiler.

Imagine that it is. Then no one can use any compiler that does not give an explicit permission to copy compiled binaries in its license. Now check out any compiler license from Microsoft, Borland, or Sun. Is the permission there? Check out your Notepad and Word licenses too. Do they give you an explicit permission to copy text files that were processed with these tools? No? You're SOL.
--

Open Source and Guilt

[rmpotter]

Here are some rather obvious observations, though I seldom see much reference to them during the time I've been reading /.

Seems to me that most OS code has been developed by coders who have been supported in whole or in part by universities, benevolent corporations (large enough that they can't keep track of what some of their employees are doing, perhaps ;) -- and of course programmers who still live at home and are supported by their parents.

Because circumstances allow this code to be developed for "free" -- it seems right that it should be released (with source) for free.

Code developed in the marketplace -- where the software developer assumes all of the risks and costs of development should have some rewards. Developers should not have to ask for remuneration by dangling support, upgrades or plain old begging. Whether or not the source can or should be released to the end user depends on the application/cost etc.

In any case, why should programmers feel guilty about selling a good piece of code?

What about the "millions of eyes" benefit of Open Source? No question that a large number of programmers have helped turn Linux into a viable server platform (I think the jury is still out for widespread desktop use).

I submit that for some applications, software is best improved by setting up a feedback loop with millions of CUSTOMER eyes -- not PROGRAMMER eyes.

So, if your company can muster the resouces to sustain the development of its software, then setting up a feedback loop with customers to further development seems like a good strategy. Let your customers "direct" the development by providing feedback on the features and functionality they desire.

Depending on the product, opening up APIs or code (with some reasonable restrictions) may turn out to be a requested "feature" -- or not.

Making money in software

[homebru]

Ways to make money:

Sell add-on modules to the basic package.
Sell interface programs (from your package to other software packages).
Sell pre-loaded database of industry-standard (non-copyrighted) data.
Sell pre-loaded database of specific (licensed) data.
Sell pre-loaded database/catalog of vendor-specific data with an agreement from the vendor paying you a comission on product sales due to your software. (Major opportunities here.)
Sell custom code modifications.
Sell installation and training.
Sell services (remote application/data hosting).
Sell the associated (and required) big-buck database package (i.e., be an Informix, or Oracle reseller).
Sell software upgrade contracts. (Send notice/cd-rom when software is updated.)
Sell software support contracts. (Dial-in and telephone.) Assumes basic package is limited or no support.

OK, that took less than five minutes to come up with.

Thing is, figure out which you can do for least up-front outlay. Then offer that product/service. If it costs you nearly nothing, you don't lose big if nobody wants to buy, and you still have an impressive product/services list. The fact that not everybody will buy a particular product/service does NOT mean that NOBODY will want it.

Add to your product list. Keep adding to it. Don't let people think that you are a "one-trick pony". There's a world of folk out there who only want (for example) general ledger and accounts payable but who will not buy unless your product sheet shows payroll also.

I spent over eight years learning these lessons. If the moron who owned the company had learned any of them, we'd have made big bucks. He didn't; we didn't.

Good luck.

Promise GPL after _X_ years?

[Booker]

Perhaps you could release it, and the code, but with a restrictive license that doesn't allow redistribution... for the time being.

You could put something in the license, though, that says "in 2002, this license will be null and void, replaced by the GNU General Public License (see Appendix A)"

That way, people have a warm fuzzy that the product has a life even if _you_ choose to move on to other things, they get the source right up front if they need it, and it still looks like you "get it." :)

What do you think?

---

Customers fixing code

[Kipli]

You write:

However, they will become more and more knowledgeable with the software, especially from the user-side. This will extend codewise if they can get the source easily. There'll be situations where they want to fix stuff themselves, in order to meet deadlines and other things.

I don't quite agree. The time it takes to determine that a bug exists, locate the bug in the code, figure out what the fix should be, test the fix to make sure it works, test the fix again to make sure it didn't break anything else, then to implement the fix, is just too much for most people.

It's not that they aren't intelligent enough to read code and see the problem -- I can usually do that, and I'm not a professional programmer -- it's that it often requires a significant amount of time and mental energy to wrap your mind around a problem. I don't want to take *my* time fixing *your* code, even if it's something that I need done quickly. I have more important things (to me) to do. Instead, I would prefer to call you up, describe the problem, perhaps give a rough explanation of what I think the bug is, and then be able to say "Our service contract says you'll take care of this. When might I expect an updated version?"

I don't think that open sourcing would drive companies away, unless they had enough resources to dedicate people to understanding and maintaining the code in-house. In that case, they're not buying the product anyway, and wouldn't be interested in a service contract either. However, it may pull in some people who would like to know what's going on inside that box on their desk -- people like me who like to tinker around with the code, but don't want to have to rely on my own skills to get some jobs done.

kipli

Nonsense. Selling copies is perfectly valid.

[TheDullBlade]

Now this is important, so I'm gonna repeat it twice with increasing emphasis:

You don't need to license software you sell.

You don't need to license software you sell.

You don't need to license software you sell.

If you own the copyright, and don't give out any licenses, only you can make copies. Copyright law allows certain uses by anyone who buys a copy of software: installing it, running it, and making a backup. Very simple. No need to involve vicious packs of lawyers who piss off your customers and chew your profit margin to bits.

The standard practice of shrink-wrap licences is both unnecessary and legally questionable. Go ask a lawyer and he'll tell you that you should pay him more, every time, as long as he thinks you can make the payments (here's a hint: they ain't in it for the satisfaction of helping their fellow man). That's why everyone ends up with license who asks a lawyer, not because it's in their interest to have one, but because it's in the lawyer's interest to tell you to pay him for one.

Study the damned law yourself! Trust lawyers to tell you how much you should spend on lawyers, and you'll end up watching them suck you dry. (definitely don't trust me to tell you what to do. go check it out yourself. I could be lying, but I'm only telling you things you can easily check yourself)