Thanks to Mabimal for the great questions and comments on open source monetization. Recently, on April 29, 2009 at 11:02 PM EDT, Mabimal asked the following:
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.
No comments:
Post a Comment