SUN开源软件的商业思路

Productizing Open Source Projects - The GlassFish Approach
  Posted by pelegri in OpenSource

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 . 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).

The way these bug fixes are provided involves creating a source branch under tight control so that only bug fixes are added, and running full test suites, and then delivering a stream of releases addressing the important bugs, with a tradeoff between fixing many bugs and ensuring that there are no regressions. All the companies that I know that provide enterprise-level support for a product do this type of branching, and whether the code base is open source or not does not change that. The lifetime of the code branch depends on how long support is provided: the longer the support the more expensive is to provide it, as the branch and its associated resources (tests, machines, configurations, engineers) have to be maintained active.

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.

In general, the goal is to push the changes from the support repository to the main one but that may not always be possible. In the case of GlassFish / SJS AS, the same groups are involved, so this is not a problem. The bug fixes are pushed through to the main repository where they are combined with new features so later releases will include both features and bug fixes. This arrangement works well for all parties: customers are provided good support and at a good price - otherwise some other provider will use the main repository to provide support - and Sun can get revenue from support.

The last mechanism involved is stabilizing releases to the level expected by enteprise customers before declaring them final. There are two basic approaches about this. In one, the stabilization is done in a separate branch; in the other it is done in the main branch. GlassFish follows the second approach: we stabilize and remove all bugs in the main repository, the final release of GlassFish v2 is going to be identical to SJS AS 9.1.

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.