Dr. Harry Foxwell was kind enough to provide me with a copy of his GREAT book on OpenSolaris. The book is extremely well written and a must buy for all those interested in the best operating systems in this universe. A little history here - I interviewed Harry prior to him coming to Sun in 1995. Harry has been a fantastic SE and an even better friend. Harry likes to exxagerate how hard the interview really was. Now, I have to admit that I was going through my Patterson and Hennessy Computer Architecture phase, so I was treating prospective candidates as if they were postdocs at either UCB or Stanford :-)
As Harry signed below, "This will help Solaris "go to 11"!
Below is the cover of Harry and Christine's book.
Apress's Pro OpenSolaris is the second English language book to be published specifically about Sun Microsystems' OpenSolaris open source operating system. The first was the comprehensive,1000-page, OpenSolaris Bible published by Wiley in March 2009. That book purposely covered all aspects of OpenSolaris for those with only basic familiarity with Solaris and UNIX as well as for those with greater administration and developer experience; it reviewed desktop tools, networking, shell programming, and system administration along with the unique features of OpenSolaris.
Pro OpenSolaris, published in April 2009 and based on the OpenSolaris 2008.11 release, assumes the reader is already comfortable with the user and development environments of GNOME and Linux; it focuses primarily on the key OpenSolaris features that should be learned and exploited for Web development. It includes an extensive chapter detailing a sample Webstack project based on the zones, ZFS, security, and SMF topics introduced in the preceding chapters. The book also highlights relevant online references and resources for further learning. Although all of the information about OpenSolaris is available on myriad Web sites, books such as Pro OpenSolaris give you a roadmap and recommended sequence of what to learn first. It also strongly emphasizes that open source solutions can be effectively hosted on OpenSolaris as well as on Linux.
You can purchase Pro OpenSolaris here at Amazon or at Barnes and Noble.
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.