One place where it's very easy to compete OSS is in the enterprise. For an enterprise, the license cost of software is only part of the total cost, which includes:
* Piloting, operationalizing, and deploying the code.
* Staffing maintenance and support.
* Training.
* 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.
One place where it's very easy to compete OSS is in the enterprise.
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"
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:
Proprietary software can be more open by providing an api and tools to allow others to create extensions and customizations without consuming your resources. Creating a community of developers may be more important than some specific set of features.
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
commercialversion.
What if your competitor takes your open source code, adds a little bit of value, and sells cheaper than your commercial version? Or, if there's some clever (algorithmic) thing you are doing, what if he uses your ideas to better compete with you?
If a competitor takes your code, modifies it, and resells it as closed source software, you sue and win.
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.
If a competitor takes your code, modifies it, and resells it as closed source software, you sue and win.
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
"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.
I don't believe this is always true--usually the superior* fork wins out. Take Firefox or xorg. Both of them effectively replaced the projects from which they came.
* Where superior here means technically, or aesthetically or friendlier to contributers or whatever.
On a market a single law applies: the product that is better marketed wins out.
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.
That's a much better situation than keeping everything closed and having a competitor surpass you, assuming copyleft. Someone always will if they want the market badly enough, but with OSS, you have the advantage of the source of the competitor's changes as well. So, if they create something really cool and start marketing better, you integrate the really cool into your software in a cooler way, and then figure out how to market better than they're marketing. Everyone wins. : )
Yeah. It's also just all about risk. People overestimate the risk of competitors stealing trade secrets, and the impact that might have on their business. And then they drastically underestimate the risk of sucking out because nobody ever uses their product.
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. ;)
if the "adds a bit of value" is enough for your customers or new customers to switch to the alternate product then you were missing something all along that your customers wanted that you weren't providing, so:
* 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.
* Piloting, operationalizing, and deploying the code.
* Staffing maintenance and support.
* Training.
* 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.