Productizing Open Source Projects - The GlassFish Approach
By pelegri on Aug 30, 2007
The question may start with "What is the difference between GlassFish and SJS AS?" Or, "What is the difference between how RedHat and GlassFish productizes Open Source?" Or, "Can you provide support for GlassFish?"
I've explained this topic a number of times in the last few weeks, so I'm going to write it down and next time I'll just send a URL to this entry... I earlier wrote about Commercial Support for GF, this time I want to explore a bit more the process mechanics.
The first observation is that different customers have different needs and the features of "products" will vary. For now I'll focus on the traditional enterprise customer and on deployment-level support because that is what we are providing today for GlassFish. What such customer wants is insurance that deployments will not break, so what they want is help, early warnings, and bug fixes, but not necessarily the latest features (the same customer may also want the latest features, but that is likely to be from a different group, or perhaps the same people but under a different role).
A sustaining branch is key to provide support but the main main development will keep moving on. There are different ways to treat these two code repositories, and that varies depending on the relationship between the groups maintaining the two repositories, on the business model involved, and possibly other factors like the length of the releases, etc. A change that occurs in the support repository but does not migrate to the main repository needs to be reapplied the next time a supported release is created, and, if the main repository has changed a lot, this may be very expensive, risky, or just impossible.
The GlassFish approach is resource efficient, otherwise we would need to run tests twice and provide separate documentation, etc. Also, for the reasons described above, this approach does not negatively impact our revenue. But this approach implies a substantial level of investment in the project and a buy-in from the community with the enterprise-quality goals for the project. When those are not present, a commercial vendor will need to do the stabilization in a private branch, and then get those changes back into the main branch, with the extra cost and risks associated.
... Does this help? Ask questions in the comments, and, if necessary, I'll provide an improved version later.