Slashdot Mirror
Making Money With Open Code, APIs, And Docs?
"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."
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 :)
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
Jon Erikson, IT guru
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.
-- the most controversial site on the Web
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.
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. 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.
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.
I'm old enough to remember when discussions on Slashdot were well informed.
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.
proof, n. A demonstration that a conclusion is implied by certain premises and axioms.
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.
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?
---