The degree of choice and customization that open source affords is one of the key selling points that sets it apart from proprietary solutions (every bit as appealing as the lower cost of acquisition, from many organizations’ perspectives). But when organizations start mixing and matching different open source technologies, they find that “open” doesn’t necessarily mean “interoperable” — and incompatibility between different open source technologies can take down systems just as easily as interoperability issues between different proprietary products can take down systems or applications. “With open source projects we can sometimes get seduced by their promise and skim over the effort it takes to get it all to work together, the license issues for dozens of applications included in a particular stack, or even the complexities of mixing open source with proprietary and commercial software,” according to Steven Grandchamp, CEO of OpenLogic, a company that provides software and support to help enterprises manage open source. “Often different teams, groups or divisions are using very different sets of open source solutions. Large companies often don’t know where it is, how it’s used, or what license it is under.” In the Windows world, Microsoft has a great deal of control over their operating system, database tools, software. While that doesn’t mean that there aren’t common failures and problems — there is a single point of control over the discreet components. Today’s news that Microsoft was taking efforts to interoperate with ODF was an interesting example of how a proprietary vendor’s customers can pressure that vendor to create better interoperability with open source solutions.In the open source world, typically there is no single point of control, and no assurance that one technology will work with another. People generally start out with Red Hat Enterprise Linux, Novell SUSE, or another popular Linux distro. Then they go onto the open Internet and start playing with individual open source projects (on SourceForge, there are currently more than 122,000 registered open source projects).Over time, an organization can accumulate a ton of different open source technologies under its umbrella, and when incompatibility issues start popping up, the user often doesn’t know who to call when a system or application goes down. Further, the company likely does not have a very disciplined understanding of all the different license restrictions on the open source technologies they’re using, which introduces new liabilities in an audit scenario. The point isn’t to induce a sort of hand-wringing anxiety about open source use in enterprise. Open source is a fact of life today, and ultimately these interoperability issues are much easier to solve between open source solutions than they are between proprietary solutions. With the news that Sun is open sourcing Java, we’re going to see the open source integration and compatibility issues continue to become more complex. As Sun exec Rich Green said in a CNET Q&A that ran today, “Java is more advanced than, I think, any other open-source software in terms of compatibility testing, the availability of (testing suites) and other things like that.” So what does that mean for the organizations whose employees start tinkering around with open source Java, and building new applications with complex dependencies on the JVM?When Red Hat announced earlier this year that it was kicking off its own open source certification efforts, a lot of media outlets suggested it would be the death of the crop of start-ups that are addressing compatibility and certification for open source stacks. But I think with the degree of customization that takes place with open source adopters — and the sheer volume of open source point solutions being adopted — the complexity of keeping a handle on these systems will support a pretty large ecosystem of vendors like OpenLogic, SpikeSource, SourceLabs and the like. Technology Industry