I should have blogged about this announcement of my new role when it occurred on June 4th, but I was so busy with JavaOne and a lot of customers, that I have not had the time for blogging.
Since this is the first day of Sun's FY10 and I am on vacation here in Ocean City, Maryland waiting for the morning fog to burn off, I thought I should mention my new role Chief Technologist (CT) for Global Systems Engineering (GSE) in the Software Line of Business (LOB). That is a long title, but one that I am very, very excited about and thankful to have this new role at Sun. I was the CT for North America and then the Americas (including Canada and South America).
Sun is still second to none in the ability to create strong software communities in the open source world. We are continuing to tweak the monetization framework to adjust to this evolving economy. Without question, open source already has won and it is just a matter of time before everyone realizes this.
Below is a snippet of the text from my announcement on June 4th, 2009.
Dave joined Sun in early 1987. In 22+ years at Sun he has held a variety of positions working with a broad range of products and applications for a wide ranging set of customers in both commercial and government markets. Dave has been in the computer industry since 1978 and has held programming, management, sales and systems engineering leadership positions for a variety of companies, and has been working with Unix since 1981. Most recently, Dave was the CT for North America's SW Practice holding this position for almost five years.
Dave led the creation of Software Genius University (SGU) with some of our top SEs in the Software Practice and across Sun that delivered 760 hours of content. Each week, Dave hosts a technology webinar, with Brian Leonard, for Sun's global
employees and Sun's global partners.
Dave was the "father" of the Mid Atlantic Area Technology Center for Sun. This multi-million dollar Center had over 300 customers through it in just over seven years and has posted world class industry leading benchmarks. The Center won the 1996 World Wide System Engineering Creativity Award.






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.