OSBC 2007 occurred over just two days last week (Tue and Wed), and here we are, one week after the event, and I am still in the midst of following up from all the great meetings and introductions during the show. This was truly an incredible event, with the most positive energy and optimism I’ve seen in a trade show in years. Many congratulations to Matt Asay and the folks at InfoWorld for organizing such an excellent event. The quality of people both exhibiting and attending was outstanding, and afforded a steady, literally non-stop stream of constructive and insightful conversations, many of them regarding the OSA.
Open businesses are truly taking the world by storm, making further and further inroads into markets formerly dominated by proprietary alternatives. This was the case across a wide spectrum of open businesses I met with, ranging from ISV’s like MySQL, AdaptivePlanning, EnterpriseDB, Jive, Funambol, Groundwork, Liferay, Mulesource and ZenOSS, to integrators including Optaros and Unisys’ open source practice, to the OSS-focused business units of larger platform vendors such as Intel. By choosing to be open, these organizations all believed they were ultimately more competitive and better able to meet customer needs than the alternatives.
But what was particularly interesting was the spirit in which this optimism was being conveyed. What became apparent throughout many conversations was that these weren’t just companies that decided to make their source code available (or, for integrators, to work primarily with open source products), but were taking the spirit of open-ness and collaboration to heart throughout their business practices....
Among them were marketing managers talking about the
“four P’s” of their offerings, business development managers talking about how they structure their partnerships, or product managers talking about their roadmaps and processes for managing their product requirements over time (think of PM as a facilitator, not a dictator, of product requirements). In all cases, there was a remarkable tone of open-ness and transparency, a sense of “what you see is what you get”, and the confidence that being open and honest in one’s dealings (and accepting nothing less than the same in return) would result in happier partners and customers. There was little of the smoke-and-mirrors that typify a closed company, no trying to “manage” what you know and don’t know about them, no trying to spin short-comings. Nor was there a fear of their open-ness being used against them. Being open about one’s business leaves a company no more vulnerable to competition than
open source code being vulnerable to viruses and security threats. Instead, it forces you to be honest about your strengths and weaknesses, and you become a stronger organization than you would have otherwise.
It’s difficult to imagine what “closed” companies will do in an increasingly open world. Companies that insist on remaining “closed” will become islands in an open world, and perhaps resort to counter-productive tactics to defend their market position, with their customers and partners preferring to work with open alternatives with increasing frequency. More on this in a later post....
As we have discussed here in previous postings, this spirit of open-ness is the core of what the OSA is all about. By choosing to operate in an open and collaborative fashion, we can collectively address some of the toughest challenges in our industry in ways that a proprietary vendor would hardly ever dream of. Indeed, many of my conversations (about 10) were with companies expressing interest in joining the OSA, attracted by our good-faith effort to address key issues best solved in a collaborative effort. Each company claimed to have an “itch to scratch” (to borrow a euphemism commonly used to describe why developers contribute to open source projects). The “itch” differed from company to company, but the common theme was that each issue could be better solved through collective effort instead of unilateral initiatives. For management companies, how to encourage application vendors to expose consistent APIs for administration, management and monitoring. For business applications, there were several “itches”, including data integration, single signon, and so forth. For integrators, there was particular concern over inconsistent support SLA’s, and also inconsistent use of various standards that enable extending and customizing appplications. And so forth. But each member was looking to the OSA to foster and facilitate working with other like-minded companies to work through their specific issues.
The OSA’s structure and governance was organized to facilitate this kind of grassroots behavior. Each member has different concerns, but share the common goal of addressing them in an open and collaborative way. With enough members driving enough initiatives, the aggregate effort will be game-changing. Not only will we address these common problems, but we will further validate that open and collaborative behavior consistently trumps closed, unilateral behavior.
