If you don't have 38 minutes to watch the entire interview, but want to know more about Apache XMLBeans, Apache Beehive (which is currently incubating at Apache), how these projects relate to the JCP, or my views on open source strategy, you can just take your pick an individual clip. I'd certainly love to get any feedback.

I guess I should probably blog separately for each of these topics, but for now here's a quick thought on corporate use of open source:

I've seen a few articles in the media lately about companies that open source their products in order to end-of-life a product or produce a short burst of marketing excitement about a product that isn't going anywhere. While there are companies out there doing that, I can tell you that couldn't be farther from the truth about BEA's reasons for open sourcing XMLBeans and more recently, Beehive. There were many reasons to open source these projects (none of which have anything to do with charity, by the way):

• grow the Java pie (a pie that BEA has a direct interest in) by making J2EE easier
• remove any unintended lock-in concerns that customers might have by taking a proprietary innovation and removing the proprietary part
• significantly enlarge the user base of the technology that our customers are already using today. A stronger ecosystem around the technologies that our products depend on means more value for our customers.
• improve our competitive position by making our core programming model a required commodity. Lots to say about this one, but it will have to wait for another blog.

These are just a few reasons that have nothing to do with marketing or tossing a dying product over the wall. Instead, these are objectives that a corporation might use to provide more value to its shareholders, while also serving as an incentive for the corporation to do everything it can to make the open source community as strong and diverse as possible. Aligning strategic business objectives with the interests of open source communities is essential for the success of any serious corporate involvement in open source.

Why

• Investment Protection: not being locked into one product in order to continue to access data that was created using it, or to use an application that was built using it.
• System Integration: making multiple systems talk to each other when they are under one's control. With some configuration, systems can safely exchange data.
• Interoperability: making multiple systems talk to each other when they are generally not under one's control. Ideally, interop standards should not require configuration changes or coordination on both ends of a communication to exchange data. WS-I is an example of a standards organization attempting to narrow the configuration options to achieve true out-of-the-box interoperability.
• Skills Transfer: investment protection for brains. Developers and end users would prefer to reuse their knowledge and experience from one system to another. Just how important is this concern? It was certainly useful for the SQL language, even though full code portability was never realized. Do customers still care about skills transfer?

What

• Protocols: allow two disparate systems to exchange data. Standardization is essential to creating an open network.
• Formats: allow the data to be understood by the systems after being exchanged; also enables investment protection by allowing open access to data. The widespread adoption of XML and HTML demonstrates the value of standardizing formats.
• APIs: could be considered formats for source code; APIs enable code portability. Without standardized APIs, customers risk locking themselves into a vendor's programming model. J2SE and J2EE are examples of successful API standardization efforts. Do customers reject all nonstandard APIs, or can a vendor offer a solution so compelling that a customer would rather take advantage of productivity gains than wait for standardization?
• Tools: how much do customers care about standardization of tools or tool environments? What concerns would this address?

Where

• Accredited Standards Organizations: relatively few standards bodies are actually accredited by national or international organizations; exceptions include ISO/IEC, IEEE, and NIST.
• Consortiums: W3C, OASIS, WS-I, and the JCP are all non-accredited organizations for fee-paying members to participate. Some consortiums are more open and vendor-neutral than others. Intellectual Property policies also differ across these various consortiums. Since none are accredited, what makes a customer decide whether to invest in standards from these organizations?
• Volunteer Communities: the IETF is the classic example of the volunteer, de facto, standards organization. With the widespread use of Struts and other Apache technologies, one might wonder if the Apache Software Foundation is another example of a volunteer de facto standards organization.
• Vendor Agreements: when Microsoft and IBM agree to a specification, is that accepted as a standard? What about when BEA and SAP join them? At what point does a spec go from being proprietary to open? How large and how diverse does the party need to get?

Who

• Market Leaders: without at least a few of the major players behind a standard, customers will not be willing to invest in it. This is true whether the standard comes from ISO/IEC or the IETF.
• Broad Market Adoption: customers get concerned when a specification is not being adopted by a large enough ecosystem, even if there are one or two major players supporting it.

When

• Shipping the Standard before having Implementation Experience: while standards organizations like the Java Community Process require a Reference Implementation as a proof of concept, real-world use of a technology cannot be substituted for a code drop.
• Shipping the Product before Standardization: Of course, the side effect of getting real-world implementation experience is that users will begin to become attached to the nonstandard technology and will likely run into compatibility problems as the standard evolves.

How (the 6th "W")

• Degrees of Compliance: how does a customer feel about 95% compliance? how about 110% compliance (the standard plus vendor extensions)?
• Innovating Ahead of the Standard: should all innovation occur within standards bodies? If not, how does the responsible ISV innovate without threatening customers with vendor lock-in? Is there an acceptable period of time that an ISV can ship a non-standard technology (one that would qualify as a technology requiring standardization)? How much pain can a customer put up with when migrating from the original innovation to the new standards-compliant version?

While there are more questions here than answers, I'm hoping this exercise will help me in future blogs to dig into the details of what makes a "standard".