Open Source Business Models: Rethinking the Sun Model
The Sun Model was recently unveiled by Simon Phipps in a sort of open source veni vidi vici, easing adoption, fostering communities of users, focusing business opportunities on the creation of value between deploy and scale.
Rich Sands – formerly marketing guy behind the OpenJDK project – commenting Simon’s post suggested to position Sun’s offer somewhere between delivering hardware and professional services, while Savio Rodrigues invited MySQL (and Sun) to reconsider closed source. Both ideas worth some consideration, and I want to add my perspective to a subject that I have been covering few times in the past.
Rethinking Open Source Strategies by venegas
The Sun model seems similar to many other open source vendors’ business strategies, as originally argued by Savio, and it lacks to consider other opportunities than selling just add-ons to scale. Let’s see some of them.
Open source franchising, an idea that apparently Simon was thinking of more than one year ago, may sounds too expensive during economic downturn. All in all running a sort of “pilot” could be manageable, though.
Dispersed knowledge about how to use open source software packages, often available through forums, directories, newsletters and consulting firms, could be made available to customers for a fee. Probably there is a word of opportunity to create more value out there. Customers conversion is critical, true. But customers look for a “whole product solution”, and it is up to you provide them with the value they will pay for. OpenOffice migrations could be an interesting opportunity, otherwise IBM might end earning the most doing the least.
Open source ISV should look for their own “open source marketing funnel“.
Open source network marketing is another option, I’ll leave this for another post.
Roberto Galoppini, 
Savio Rodrigues 9:58 pm on November 10, 2008 Permalink
Hi Roberto, it’s hard to make broad statements that cover all vendors or projects….
But I will 😉
>Dispersed knowledge…
Selling documentation is a tough business…
I think implementing software is always a ‘business’…but customers tend to pick the creator of the software to implement the software.
Simon Phipps 10:37 pm on November 10, 2008 Permalink
I purposely left the third phase as open as possible. All that you describe is included, as well as options like servers optimised for MySQL, ideal for people between deploy and scale. Expect hybrid offerings to include not just tuning tools and extra features like Rich considers but also targetted appliances and unified storage built using the same open source solutions.
Richard Sands 12:33 am on November 11, 2008 Permalink
Hi Roberto,
I think you’ve got exactly the right idea with “other opportunities”. Any business model hoping to leverage something thats free – open source or otherwise – has to use the adoption garnered by “free” to sell something else. Anything else. There’s lots of possibilities. The challenge is to find enough revenue in all those something elses to justify the engineering necessary to build something that is good enough so that people will use it, zero price notwithstanding. Here’s another example of how to sell something else, that leverages broad adoption – again from Sun: http://tinyurl.com/5hprbu – really no different than selling screen real-estate on your browser window based on ubiquitous search engines.
Roberto Galoppini 10:14 pm on November 11, 2008 Permalink
@Savio: selling documentation wasn’t a difficult for JBoss, and I believe that OpenOffice.org migration guides, as well as tutorials and other infoproducts might be welcomed by the market.
Creators are the first choice, I agree. But open source is different, and we see system integrators all around the word appropriating returns from commons, as small open source vendors unable to fulfill customers’ needs worldwide.
@Simon: I really enjoyed your second post, check out also my second one.
@Richard: great example, really! I think that engineering is just part of the “whole solution product”: tutorials, methodologies or knowledge bases need (just) human editorial efforts, and they can be even the result of collaborative projects!