By stern on Jun 24, 2007
I need to rewind a bit to my west coast with a hop in Ohio trip. It was one of those trips that had a little bit of everything: delayed flights, tight connections, extra-long meetings, really great customer interactions, and a chance to peek around the corner at what's coming next for Sun. The common thread (except for really egregious tuna salad wrap I ate in Newark airport) was wrapped around communities.
We've been talking about communities for about two years, mostly as an adjunct to our open source efforts: taking Sun software products and completing the legal, licensing and structural work needed to make them fly as open source projects. One of the comments that is repeated regularly - because it's true but not entirely understood - is that communities take work. You have to work hard to build them, but at the same time you don't want to turn the community into another channel for your marketing or sales efforts. The community has to stand on its own, with gentle help, guidance and contribution by a variety of members. That's true for your town's planning board, the board of education, youth sports organizations, or open source projects. You have to attract the co-developers, and make the community an attractive place for deployers to come, learn and share their experiences.
The folks in the picture on the left are what makes the Sun customer engineering community a strong force. Despite arriving at midnight, our Ohio Valley SE superstar Brian Howard [note: corrected name and title] was there to meet and greet. It wasn't just sucking up to another vertex in the org chart; he really does believe in making sure his people are settled. It was evident when I found members of all of our technical sales practices, not just "our" Global Systems Engineers, in his rapid-fire customer engineering meeting. Internal communities give you leverage and scale.
Two days later, I had a similar org chart sub graph mapping problem imposed on me, when I hosted some of our Campus Ambassadors (shown on the right) at a meeting of Sun's Executive Leadership Team (aka Jonathan's staff meeting). The campus ambassadors work for Sun but are responsible for building communities at their colleges and universities, typically by starting and encouraging OpenSolaris user groups, stimulating developer interest in NetBeans, and leading by example. They provide a link to the next external community members: the (co-)developers, deployers, and architects of whatever (and wherever) from which the next big thing evolves.