Okay, I didn’t really want to write about Sun again today, but Simon has an interesting post about the “Sun Model” for open source business. Simon states that the model boils down to:
“1. remove barriers to software adoption between download and deploy;
2. encourage a large and cohesive community of software deployers;
3. deliver, for a fee, the means to create value between deploy and scale, for those who need it. “
I’d argue that this isn’t the “Sun Model” as much as it’s the general open source software business model. Wouldn’t you agree? The trick has always been step 3. To this point, Sun’s Rich Sands writes the following comment on Simon’s blog:
“The tricky bit with this model is that it is too hard to make enough $ to justify all those engineers. Why? If the code base is commercial quality (a given with Sun), deployers often don’t need your services or add-ons to scale. They can figure it out themselves, or only a small fraction of deployers will scale big enough to need extra help. Or the community just builds a free alternative add-on.
The real Sun model, which could work, but is seen as unpopular with analysts and investors and people focused on everything “paying its own way”, is that ubiquitous software platforms driven by potent open source development and deployment communities creates “opportunities to monetize” hardware and services – aka “drag”. You still need racks of humming machines to run all that free stuff. Sun’s challenge: deliver hardware and professional services that run the free stuff with better ROI than anyone else’s gear. Then, figure out how to account for the drag, so that the software strategy of creating ubiquity and mass adoption gets credit for dragging all that hardware along, and the credit justifies all those engineers.
— rms | @richsands”
Rich makes a great point. When the code base is of commercial quality, do customers really need a vendor’s services or add-ons to scale? Or if a set of customers do, can the revenue offset the cost of delivering the software?
The answer that I back is to differentiate between capabilities within the for free open source version of the product and the for fee version of the product. MySQL tried to do this last year, but had to backtrack due to community pressure. It was the right thing for MySQL (and Sun) then, and remains the best move for MySQL (and Sun). It won’t be easy to grin and bear it as the community throws tomatoes. But the open source ecosystem will be better off for it.
Can you think of a better testament to the power of the open source business model than saving Sun Microsystems? Without a way to convince a significantly higher percentage of users to become customers, Sun’s open source success, while great, will get lost against the breakdown of its high-end enterprise systems business.
Marten (& Simon), it’s time for you both to get your tomato-proof goggles and drive the differentiated product strategy again.