Castellers

I was recently visiting a software group at another company in the area and at some point we ended talking about how information flows in our companies. Their company keeps information flow very tightly controlled; even within the company a group often does not know what other groups are doing. By contrast, I pointed out that I often get my information from Blogs.Sun.Com.

The secrecy or free flow of information is a reflection of the underlying business model: the traditional for-fee Right-to-Use license (which may or not include support) versus the new model based on free Right-to-Use plus optional for-fee support. In the new model the penalty for making most information public is very limited, while the efficiencies of the free flow of information are huge: agility, reusability, connectivity to the customers, architectural review, etc.

There are a few specific cases where it makes business sense to keep some information confidential, like some performance benchmarks, and in some cases privacy may even be mandated, like in pre-released SPEC results, but otherwise, the benefits of public information greatly outweight the disadvantages. Blogs in particular have been extremely useful in addressing large Time-Zone distances and in providing a practical virtual alternative to the water cooler.

Here is another example of the impact of the business model: in the traditional model preannouncing a release might kill substantial revenue but in a subscription-based model there should be no negative impact and actually the opposite may be true! We have often seen sales happen because the future roadmap can help sell the current release.

The move to Open Source has deep implications for the software industry; in more ways that one We are not in Kansas anymore! The next few years will be fun!

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

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.