I was asked on my blog regarding open source by Mabimal on April 17, 2009 at 05:49 AM EDT the following:
Hello Dave,
It's nice to update my knowledge on open source, but i m always eager to know how do open source project get revenue. Can you please provide the details on that?
Mabimal, sorry for taking twelve days to address the real key point of open source. I should have taken the time to address it as part of the initial posting, but then thought I would do it separately. Since the 17th, things have changed for Sun Microsystems, but my core belief in the importance of open source and how we need to frame open source monetization has not changed.
First, my early thinking on open source has been largely shaped by Scott McNealy, Bill Joy and Rob Gingell. My thoughts on open source monetization has been largely shaped by Rich Green and the two founders of MySQL - Monty Widenius and David Axmark. I really believe that Rich Green was on the exact right track prior to him leaving Sun.
Prior to Rich leaving, he was in the process of standardizing our software strategy much like MySQL had already put together. My personal belief is that it is absolutely critical to have the Dave Edstrom 4 Cs as I like to call them:
Consistent is the most important to really drive volume. You can not have each Product Manager rolling their own strategy. That will just confuse the marketplace. The marketplace being customers, partners, developers, employees, ....
Below is the high level monetization framework that MySQL used. You create a community or platform with your free Community Edition. You support your Community Edition with a binary, for sale Enterprise Edition that emphasizes the unique vertical markets or massive scaling aspects that customers are willing to pay for. I have heard the founders of MySQL say this countless times. Of course, there are professional services that can go along with this.
Something that MySQL did was list the questions to determine whether or not you or your company should go with the Community Edition or the Enterprise Edition. This really helps the individual determine their own skill sets and and needs. Please see below:
The image below is what is commonly called inside Sun, the Rainbow or Donut Blue Print for Open Source Monetization. The key to this is that the light green is the community version/edition and the orange is the Enterprise Edition. The Enterprise Edition is based on a revision of the Community Version, but also has the massive scaling, industry specific addons , 24x7 support, best practices, hot fixes and enterprise monitoring that large enterprises will want/need **IF** they do not have the in house expertise. My personal opinion is if you think you will make all your money off professional services and indemnifcation, you better go back and do some more financial modeling. Speaking of Professional Services, this is predicated on having a strong support and services organization.

I believe that we will see another layer to this model and that is cloud services. You can not simply throw your applications into a cloud and think you now have a cloud. That is like putting a 638hp Chevrolet Corvette LS9 ZR1 engine into a Vega and thinking you now have a sports car :-) More on adding the cloud layer to the donut or rainbow later.
Hope this helps Mabimal
....
There are many individuals who are confused about open source and monetization.
The first two rules on open source and monetization come from Marten Mickos in 2007 who was CEO from MySQL at the time:
“Success in open source requires you to serve:
1. Those who spend time to save money
2. Those who spend money to save time."
The important concept that Marten Mickos is driving home is that just like every other topic on planet earth, open source monetization is not black and white, but a gray scale continuum that we are still discovering some of the finer points.
1) There is no guarantee of monetary success just because you have lots of users.
2) If you ask someone about their monetization strategy and they come back to the concept of lots of users, then they have not a clue what they are talking about. There is no direct cause and affect between lots of users and guaranteed monetization. Yes, there is tremendous potential, but just like voltage - which is called potential, what you really want amperage. If you think this is not true, go google Xerox PARC's history and let me know how well the ROI went there.
3) There are analogies between open source monetization and every day products that you used today. Do you buy a warranty for a product that has a reputation for never breaking down? Probably not, unless your duty cycle is much more strenuous than the typical user. If you are running a business and you are using free software that never needed to be updated and never broke down would you worry about service? Probably not. Are there very many examples of software that you never update? Unless you are talking about a black box aka embedded application, the answer is not too many. There is an important analogy between home devices/appliances and enterprise software. That analogy is duty cycle.
My uncle, Merle Edstrom owns his own Welding business called Cannon Welding in Cannon Falls, Minnesota. One of the metrics that Merle cares about is the maximum duty cycle for a welder. The welding duty cycle is defined as the percentage of time in a 10
minute period that it can be operated continuously before overheating. As a professional businessman, Merle's duty cycle needs are very different than your typical home owner. Quick advertisement for my uncle. If you live anywhere near the mid part of Minnesota, Cannon Welding is the best and you should call Merle for all your welding needs!
In software, duty cycle is defined many different ways, but a common link to hardware duty cycle would be the reliability of the software expressed in the classic SLA or Service Level Agreement. If my business is running a mission critical open source application (as most are these days), then having a single throat to choke, 24x7x365 support, hot patches, professional services, value added services for massive scaling or vertical industry specifics are just some of the things that I would be willing to pay for.
At Sun we are clearly defining our Community Version and Enterprise Edition software.
More on my favorite (ok, one of my favorite topics :-) later....
The Wall Street Journal reported that early reports are the stimulus package may have the following amounts for Healthcare:
This will be a great opportunity for companies like Sun Microsystems that has a very strong software infrastructure stack and known for our secure and scalable software. The canonical quote is that 40% of Healthcare costs are administrative. The other statistic that is often quoted is that nearly 98,00 Americans die each year due to medical mistakes. President Obama stated on Monday the 9th that healthcare premiums have doubled for the average family in the past eight years.
There is an article at Sun where Bill Vass brings out the following:
"So, here is the background: If the Nationwide Health Information Network (NHIN) is the information highway for health data exchange, CONNECT is the universal on-ramp for federal agencies. CONNECT is a software solution that lets federal agencies securely link their existing systems to the NHIN. More than 20 organizations collaborated to build CONNECT through the Federal Health Architecture (FHA), and as a result, agencies are heading down the road toward interoperability.
Using Sun's entire Open Source middleware stack as its foundation, including our SOA and IdM technology, the FHA built the CONNECT gateway software from open-source code. Talk about an Open Source poster child! The solution was jointly developed by federal agencies yet it will be deployed individually at the agency level. The decision to build the solution in open source provided the usual benefits (I know you have heard these from me before):
· Cost reductions for each agency and taxpayer savings
· IT consistency and compatibility across multiple agencies
· Decreased deployment times
· Security"
One of Wayne Gretzky's famous quotes is:
"A good hockey player plays where the puck is. A great hockey player plays where the puck is going to be."
Healthcare is where the IT puck will be going....
In today's incredibly tough economy and with the likelihood that 2009 will be much worse, there has never been a better time to look at Sun software. There is a well written article in eWeek titled Making Money on Technology in a Recession.
The article states: "More optimistically, CompTIA recently released a study
of 772 small to medium -size businesses that found that 51 percent said they expect
to increase IT spending while 49 percent said they plan to decrease IT
spending. The
long and the short of this is that nobody knows for sure what exactly
is going on with IT budgets in 2009, other than some companies are
trying to cut back some spending across the board, while others are
trying to cut back IT spending in some areas so they can spend more
money in other areas." Open source is listed in the number one slot as the main item to consider in IT's recession planning. I would argue that open source should always be #1 on the IT list and not because of cost, because it's smart. Most CxO's that I meet with have dual stack approach for both a legacy/proprietary strategy and an open source strategy. The open source strategy is something that most CxOs are evolving over time with the Sun's open source software being a significant part of that strategy. Sun has donated more source code than the next five contributors combined.
Licensing plays an important role in shaping an open source community. Read about Sun's view on Free and Open Source licensing.
| |
This whitepaper is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 2.5 License. |
I was speaking with David Axmark, Co-Founder of MySQL, at the Chaminade Resort atop the Santa Cruz Mountains that overlooks Monterey Bay. David made a very interesting statement that really caused me to pause and think. We were discussing open source and David said, "you are not doing open source until someone says no."
The key point David was making was that if you are open sourcing your code but retaining 100% control of your entire code base, that is not doing real open source. Obviously, there are many examples of companies/individuals doing this type of release (retaining 100% version control) very successfully, but David makes a great point.
There is a corollary on the sales side of the house that I heard many, many years ago which says:
There are not too many Laws that have both technology and sales parallels, but this is clearly one of them.
"There are two types of users - those who are ready to spend a lot of time in order to save money, and those who are ready to spend a lot of money in order to save time.”
- Mårten Mickos, CEO MySQL
This captures the true essence of the two poles of open source. I would say that most individuals are not on the extreme ends, but are someplace in the middle. Open source is a continuum. The definition of open source 25+ years ago was Bill Joy sending around BSD tapes of the source. Open source continues to evolve. Those who think open source simply means, "this is how we do our development" are short-changing what is really occurring. For those who are heading out to JavaONE, I would strongly encourage you to swing by the Moscone Center on Monday the 5th to truly see what is going on in open source by attending CommunityOne.
Hello Dave,
Thank you so much for putting efforts on creating this article.
What i understood from this article is that, open source project cannot be a standalone project as it must be backed up by enterprise versions which generates revenue for open source projects as well, and when the feature of open source project gets stable it will be transformed to enterprise version.The developers and employees developing open source project gets their income from the revenue generated from enterprise versions.
I hope i understood exactly as u r trying to make me understand.
If not please clarify me.
Thank you so much.
Yes, you are absolutely right. That is the general framework. Where things can get a little more complicated are the corner cases. What becomes extremely important is the latency or delay between the Community Version and the Enterprise Edition.
Let me give you a specific example. Let's say we have a Community Version that has nightly builds. Let's also say that we have an Enterprise Edition that was being released semi-annually. If the Community Version introduces a specific feature that the market place is clamoring for. Let's use as an example a Enterprise Service Bus (ESB ) with a new healthcare protocol adapter. If the customer base is clamoring for this particular adapter, the obvious question jumps to the forefront:
Does the new healthcare protocol adapter have to "wait" until it is rolled into the Enterprise Edition from the Community Version?
There are different ways that some companies address this situation. Some companies believe that you never, ever support the Community Version and you simply tell the customer to wait until the healthcare adapter gets rolled into the Enterprise Edition. Other companies believe that you do support the Community Version, but do it from your PS services group at a premium cost with the idea that you move your customer to the Enterprise Edition as soon as the healthcare adapter is officially supported.
My personal view is that when you are designing your Community Version and Enterprise Edition monetization framework, that you carefully review what makes sense to have as plugins that can be rapidly supported in the Enterprise Edition. Keeping with the example above, it would certainly be logical to separate out the protocol adapters to allow for flexibility in official product support in an Enterprise Edition. I also believe that it is perfectly reasonable to have certain plugins as non-open source in the outer ring of the Community Version/Enterprise Edition monetization framework.
There is a hard core group of open source enthusiasts who firmly believe that EVERY line of code must be open source and the only two driving factors are indemnification and support. These hard core enthusiasts call anything that is not totally open source as being crippleware. I believe crippleware is software that has had a critical piece of code purposely removed from it. An example of this is not allowing saves to a file or limiting the size of a particular structure or file. I do not subscribe to this view that EVERY piece of code must be open source. I believe that it is a balancing act between the Community Version and the Enterprise Edition.