* Piloting, operationalizing, and deploying the code.
* Staffing maintenance and support.
* Tracking and deploying new revisions of the code.
In fact, I think a lot of people have had the same experience I have, which is that it can be easier to sell software to an enterprise than to give it away.
The flip side of this is that for business/enterprise software, there is very little risk in just making your code open source and then selling a commercial version. Prospects will download and play with your code. They'll pre-qualify themselves, calling you only when they're receptive to the software's value prop. The people who will operationalize the free version probably weren't good prospects to begin with.
Another place is B2C. All of the following sell B2C software:
- User experience that doesn't hurt. (Have you ever put a non-technical user through getting software from sourceforge?)
- Marketing. (It isn't evil. Most of your customers know how to describe their pain to Google but they don't know how to conceive of the solution, and they probably don't know the computer can help them. Your mission, should you choose to accept it, is to explain how the link between unhappy present and happy future is use of the appropriate software -- YOUR software.)
- Speaking the users language (hint: "GPL", "XML", and "multimedia engine" are three words that my B2C page does not share in common with my OSS competitor.)
- Design. ($25 of stock icons doubled my sales back in the day. Most OSS projects do not have anyone who would care enough to secure the equivalent.)
- Answering emails such as "I can't email the hard drive to the download" with respect and patience rather than that special brand of community the question would get on most OSS mailing lists.
- A web site that sells the product/download/etc. Rather few B2C OSS sites are written by someone who sounds like they actually WANT you to hit that download button. They're like sculptors adding navels to statutes: they know it has to have one but the task is boring and detracts from the interesting parts of the project, so it is completed in as perfunctory a manner as possible. You'll never hear an OSS developer saying "This is the 47th iteration of our Download Now button. Its 350% more effective at getting the click than v1.0"
Design. ($25 of stock icons doubled my sales back
in the day. Most OSS projects do not have anyone
who would care enough to secure the equivalent.)
But its so long ago that both the before and after photos were overwritten in the the intervening years. I had icons, though, in roughly the same positions as they are currently. You can see the old version here -- not the best photo but it suffices:
They were from Sun's Java visual identity set, which was attractively priced when I started working on a Java project with a $60 budget. You can see them here:
The ones I was using were the open, save, print, and new document buttons. If you notice, they do not look like the sort of thing you would expect an elementary schoolteacher to have in her classroom. I knew the sort of look I wanted: big, bright, bold -- like a Fischer Price toy. Then one day, while browsing the Internet, I saw an icon set that gave exactly that for about the price of one copy of my software. So I snagged it, on the theory that if it resulted in one marginal sale it was worth it.
I've used those buttons continuously since August 2006, so you can see them on the front page of my website (http://www.bingocardcreator.com). Note that they're big, bold, and colorful. That increased my visitor to download conversion rate and download to purchase conversion rate, instantly. Take a gander at the difference between the 08/06 and 09/06 bars here:
As you can see, it was worth rather substantially more than 1 marginal sale.
(Wow, thats a blast from the past, reminiscing about when the difference between $300 and $500 was a huge improvement to me...)
Hope folks find it useful.
The flip side of this is that for business/enterprise
software, there is very little risk in just making
your code open source and then selling a
If a competitor takes your code, modifies it, and tries to sell it as a new open source project, nobody cares. It's a fork:
* For better or worse, real customers will stick with the "original brand".
* The fork won't get any of the community support the original did, and will always be out of sync.
* Whatever community forms around the original project will angrily reject the fork.
* Worst of all, any future development your competitor does on the product reverts back to your own code. You have all the structural advantages, as the original project owner. Your competitor is just playing to lose.
It's not like this is a supposition of mine. A great example of a project that executed this business plan: SourceFire/Snort (now a public company). Lots of companies have tried to piggyback on Snort, but for Snort's core customers, nobody has succeeded.
There's no clever algorithmic idea you can "hide" in closed-source code. Copycats are an issue (although far less of one than you think) regardless of your business model. Arbor Networks did all sorts of clever stuff under the hood (we were baselining the Internet backbone, after all), was closed source, and was beseiged by copycats.
I guess you're talking specifically about GPL-style copyleft, not Apache or BSD licensing?
There's an additional alternative: the competitor takes the code and adds features to it, then sells services on top of it. This is kind of a best-case scenario: you get free R&D.
* For better or worse, real customers will stick with the
* The fork won't get any of the community support the
original did, and will always be out of sync.
* Whatever community forms around the original project
will angrily reject the fork.
* Where superior here means technically, or aesthetically or friendlier to contributers or whatever.
Eventhough I'd love to see it otherwise, any aesthetical or technical superiority would need to come in enormous figures to even challenge the position of the market leader. For a unsurprising and worn example, look at Microsoft.
On the other hand, if some company takes your code and does better both in marketing and technical aspects, you _should_ lose! The better product is better for everyone in the developer/user base, including you. The community and users don't lose anything -- instead they gain! You do gain as well because you can incorporate the other company's changes back to your own codebase -- of course you did license the software under GPL.
15 years in the business, mostly in software, and my take is if you can trade some extra competitive risk to mitigate marketing risk, that's an absolute no-brainer.
Feel free to ask me when we're going to open-source our product. I have no idea. ;)
* Listen to your customers
* Provide top-quality support
* Constantly improve your product
you will see loyalty and a growing business through more referrals, all of which will make the other guy look like a cheap imitation.