While I was lucky enough to spend the entirety of my childhood in one town, I’ve known more than a few folks whose families were comparatively nomadic for one reason or another. Where I went through high school with many of the same kids I was in playgroup with, these people – as the new kids on the block, so to speak – were forced to continually recreate their respective social circles. One rather effective way to accomplish this, I’m told, was joining or associating with existing communities. Rather than starting from scratch in establishing yourself socially, you leverage the connections of an existing club, team, etc.
Despite never having learned that lesson personally (until college, anyway), it’s one that I’ve internalized and continue to preach to newly formed communities in the software world. What is the ambition of most software new minted software projects or products? To become popular, and thus leverage the volume to create some form of reward – be that social, financial, or otherwise. While many developers may code initially to scratch their own itch, few that I know would frown upon wide adoption of their work.
But becoming popular is easier said than done; for every LAMP component, there are thousands, maybe tens of thousands of projects that will never get in front of more than a handful of people. So how do you get from point A – project inception – to point B – widespread project adoption? Well, obviously it helps if you have a compelling project. But assuming that you have something relevant to an audience that extends beyond your family, friends or coworkers, what’s the next step?
One recommendation I often make is to take a page from the new kid playbook, and reach out to some of the pre-existing communities out there. Looking for examples? Well, the OpenSolaris crowd is doing an excellent job, IMO, in this regard. Since the open sourcing of what many (including yours truly, once upon a time) considered a soon-to-be legacy operating system, the OpenSolaris folks have made friends in the Debian (and enemies, it must be said), PHP, and now Mono communities. Many of you have probably seen the news that Sun’s considering dual licensing under the GPL – might that open them up to yet more communities? Indications are that it might indeed.
I saw much the same trend at work in the release of BIRT 2.0. Asked for a quote for the release, I provided the following:
“In the open source world, many would contend that the community behind a given project is at least as important as, if not more so, than the project’s source code,” said Stephen O’Grady, vice president of RedMonk. “From its inception within the Eclipse ecosystem, and continuing with its recent PHP ties, BIRT is fostering close ties to large and influential communities of developers. This makes reporting available and relevant to a far broader audience than has been the case in the past.”
Setting aside the fact that I’m not a Vice President (though I guess I could call myself that if I wanted to, not that it would have a lot of meaning), what I’m getting at in that quote is what I’m discussing here: more communities = a broader audience. Or as Zend’s Andi Gutman’s quote says, “We are excited to be a part of broadening PHP’s ecosystem with BIRT 2.0.” BIRT, to me, as a maturing project made an excellent decision to embrace the PHP community in its 2.0 iteration. BI/reporting and lightweight dynamic languages, after all, go very nicely together.
I should mention, of course, that allying yourself with complimentary communities is hardly a tactic of importance solely for the smaller players: Zend’s tie-up with Eclipse, for example, was an opportunity for the PHP vendor to open themselves up to one of the larger IDE communities on the planet. Zend, of course, was in turn the chosen point of entry into the PHP community for the likes of IBM and Oracle. And so it goes.
It’s also important to note that I’m (perhaps artificially) distinguishing these types of community interactions from the on-paper partnerships that characterize so many major enterprise software relationships; when OpenSolaris collaborates w/ Debian or Mono, for example, the results are available, if not immediately, with very little delay. It’s more about the code than the politics, although the latter are always involved. These types of cross-community interactions can strengthen the participating communities in the process, giving them access to new functionality, languages, tools, etc.
So the lesson, to me, is quite straightforward: if you’re new to town, and want to be popular, try making some friends. It’s tough to make it on your own.
Disclaimer: Actuate (BIRT), Eclipse (BIRT), IBM, Sun (OpenSolaris), and Zend are RedMonk customers. Debian, Oracle, and Novell (major contributor to Mono) are not.
