Business development: some considerations
“Successfull commercial open source” by Alex Fletcher, reports some interesting “must” for being a successful commercial open source firm, mostly related to deploy a strategy to balance community and business interests.
Among them I agree with the following:
- Meets the needs of non-commercial users: Products which leave open source versions woefully lacking in an attempt to force the purchase of commercial versions/licenses just can’t cut it over the long haul. Open source isn’t tease-ware for proprietary code, even if a commercial version is available separately from a community cut.
.- Actively encourage ecosystem: An ecosystem is what springs up around a useful and trustworthy product. Red Hat has been able to do what it takes to cultivate a self-sustaining ecosystem surrounding its Linux suite by building out a partner network fit with multiple support channels.
.- Continually leverage community: Finding creative ways to enable a participating community to feed value back into a product and even the commercial operation(s) behind it remains key. Funambol can boast of a global Q&A team because they found ways to stimulate its growth and development.
.- Provide some sort of IP indemnification a.k.a. CYA: Will Price might have put it best.
.- Strong open source foundation: Whether code is developed primarily through community (i.e. PostgreSQL) or company (i.e. ActiveGrid) driven efforts, the basic principles of an open source development model should be at the core of such efforts. Transparency at every appropriate level of community governance can provide an assurance of commitment to open approaches..
.
Semi-open source products don’t pay: upselling from the open source version to a more feature-rich version doesn’t pay, non-commercial users will not pay anyway. Consider also that one day another commercial open source player will deliver the missing plug-ins and modules. While for the time being it might be a rewarding tactic, it doesn’t work in the long run, you need something else to retain your customers.
Ecosystems are crucial, no matter if you’re an open source firm or a proprietary one.
But there is a difference between a proprietary channel and and an open source one: for the latter you better spend time and effort to select your partners, if they don’t really know how to deliver value you might loose prospects.
Indemnification, I believe it makes a lot of sense in US, so far despite the efforts of lobbysts, Europe is still patent free, so the whole IP thing is not important yet.
Though I believe that CYA is really important for any CIO when he/she has to define SLAs, to get things working as needed.
Fostering communities, it’s really, really important: Fletcher cited Funambol and I totally agree, they have been very good at leveraging their community. Not that easy indeed. I see some OSS firms falling in the corporate idealtype production model category trying to shift to a more participative hybrid model (MySQL, Sun just to name two of them).
A strong open source foundation is a nice to have for many new Open Source firms, but few are already implementing effective approaches. In other words, for many open source is a cost effective marketing tool, not a community based development.
Among them I disagree with the following:
- Choose the proper time to commercialize: Too much commercial influence from the onset can potentially stunt the growth of a surrounding community/user base.. .
.
If we talk about Commercial Open Source firms I think that the proper appropriate time is as soon as possible, and I strongly believe the commercial influence is not the issue when coping with communities. Most of the Problems come from poor transparency decision systems, project managers with no appropriate skills to work in a mix environment, scarse or not existent rewarding mechanisms.
Reply