New Project on the Block? Make Some Friends

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.

4 comments

So if someone in corporate America, say the folks over at Duke Energy wanted to contribute code to the community, you are hinting at the fact that corporate America may fail because they don't know how to engage.

Maybe some guidance by industry analysts on what folks in corporate America should specifically do internally (more important) and externally (important) to inject the notion of community into their own culture.

Actually, in a very real sense that's part of our community building strategy — to reach out to other communities who have already done this and to directly engage the various Solaris communities that have been out there all along. We are transforming a market into a community here, and along with that comes massive changes in behavior for everyone involved. A touch of humility is absolutely in order.

A year before we opened the project, we had the Solaris engineers going to a variety of open source, Unix, and Java conferences to talk openly about what we were planning. We had many informal (meaning non-NDA) meetings with leaders of many communities, and we were honestly looking for feedback. We couldn't always do what we knew we should do, and we couldn't always move fast enough to satisfy some people, but at least we felt were were moving in the right direction. We asked as many questions as we answered, too. Some people were shocked. Some didn't believe us. But we just kept plugging away. We did the same thing with Sun's Solaris installed base and with Solaris developers and system administrators — constant conversations among engineers. All of the most important data was collected personally by the kernel engineering team. And the more we talked the more confident we got in talking openly. The press missed this part of the story back then since we were so under the wire. But as I remember it, we basically told people pretty much everything we're doing now. Very little was held back.

So, I think what you are seeing now is an extension of that early outreach effort.

James: that sounds like an excellent idea for a blog, but i don't know that the lessons would be terribly different from the advice i'd give a vendor. in the case of Duke energy, i'd begin by reaching out to other open source projects in the .NET – and maybe even Mono – worlds. maybe begin a user community or wiki around usage of their project, so that users can begin helping users, etc.

Jim: indeed. i think we are indeed seeing the benefit of some of that early outreach. i know when i'd initially heard about the efforts to open source Solaris i – like many others – were concerned that it might be a chuck it over the wall type of effort. clearly it has not been.

now OpenSolaris clearly has its challenges cut out for it – as the difficulty in building it standalone indicate.