Think in terms of collaboration, not
feedback – the community is not your focus group.
This issue came up occasionally during the early pilot days last year.
supposed to be building a community, but sometimes we saw the pilot as
separate from our internal
program team. So, you always heard something like this: "Go get some
feedback from the pilot." In other words, we are in here
... go out
and get their feedback ... and bring it back in here for
evaluation. The problem is that you get feedback from a focus group,
a community. The culture of a community seems based on direct
participation in the creation of something, not getting feedback on
something when it's already done. Now, as a practical matter, many
people in the community do offer feedback along the way, and that's
people participate at different levels. But if you view the entire
community as simply a feedback mechanism, you've missed it. If you want
a community, you need to participate as an equal and involve people
2. Encourage people to join the
community and work from within the
community – all groups, not just the engineering implementation team.
Many times people asked me to send their stuff to the
community. Plans. Messages. Whatever. After I learned lesson #1,
though, I started telling
people that if they wanted their stuff sent to the community they
join the community and engage in a conversation about their stuff. If
it's good enough, it will fly. If not, oh, well. Try again. So, anyone
who touches Solaris in any way whatsoever should join the community --
marketing, service, docs, engineering, etc -- and do their business
from within the community by involving the community. Everyone has
something of value to
Otherwise, there's an "us" and "them"
mentality that hinders the process of building a community. Even now,
more and more teams throughout the company are engaging the OpenSolaris
community. Which is excellent. I've said it many times since joining
this project ... OpenSolaris is transforming Sun.
3. Encourage debates, but ignore
flames and competitive attacks (but
I've bounced back and forth on some of these.
First, flames. I don't like dousing flames on mail lists. If people
want to have a knife
fight in front of thousands of people on list, I'm going to pull up a
chair and watch the show. Every time I've tried to assertively put out
a flame, I
just got burned or ignored. Flames come and go. Don't contribute to
but don't worry too much, either. Just try to increase the number of
quality people on the list and the flamers will have less to say.
Second, debates. These are excellent, but they require that you educate
some people that debates are normal and healthy and generate new ideas
(as long as they don't degenerate into flames, of course). This is
generally not an issue at Sun because we debate everything
to death anyway. So, most people are used to
it. Some people, however, may be uneasy about debating across the
firewall. Take it slow and stick to what you know.
Third, competitive attacks. Now this one drives me nuts because there
really is no right answer for all circumstances, and I've never --
absolutely never -- been
convinced otherwise. It all depends on your style, your belief, your
skill set, your guts, your resources, and the competitive
situation you find yourself in. I've played all sides of the fence on
this -- the sides generally being (1) ignore them, (2) attack back ten
harder like Al Capone, (3) attack back but via third parties, so there
are no fingerprints, (4) simply correct the FUD dispassionately and
like you are above it all. They all work well in some situations and
fail miserably in others. My current thinking is that competitive
fights in public forums burn too much energy, so ignoring is probably
the best option in the long run -- as
long as you are moving fast in asserting your own agenda (or project,
or whatever). Focus more on your positive, and less on reacting to
their negative. OpenSolaris generated a lot of competitive response
because it made some people nervous out there,
I spent a lot of time defending this project in my blog. It burned me
out, to be honest, so I'm more included to either ignore a direct
attack, make fun of it, or deflect it to talk about an issue without
actually responding directly.
4. Focus on people writing and talking
about code. It's all about the
code. Don't fool yourself.
most import element here is the code
. In fact,
what strikes me most about this project is just how much the code
pervades every conversation I hear and read. It's all
about the code.
great code, and the
grows directly from how involved everyone is.
5. If you have an NDA pilot program,
run it as one team, not two.
We could have easily made our internal implementation team part
NDA pilot program itself with one list for communication. One team,
basically. For me, it
confusing ... this part is "internal" ... that part is "external" ...
be quiet here ... open up over there. In
retrospect, it wasn't necessary for most
issues I was involved with, but I suppose we had to learn this slowly
so I'm ok with it now. We're opening
more and more teams as we go, and that's great. And I'm actually
un-subscribing from various internal lists because I don't want the
traffic. I'm only interested in open conversations. Things move faster
in the open, anyway.
6. Use the NDA to define your pilot
identity and share everything with
your nascent community.
We could have done a better job at this one, but again, perhaps
we needed to experience it slowly. There was no model for what we were
doing, after all. But I
you have an NDA, your pilot community is locked in, so you may as well
open up to them, right? In some areas were were remarkably open -- to
the point of really stretching that NDA, too -- but we could have gone
further here in other areas. As it is, we learned a
from the pilot
experience, and that program helped change this company. I wanted to do
more, though. I guess my point is, don't be afraid to go further than
7. Dump internal lists or make them
We still have a lot of internal project lists. Some are
because a given project is still internal, but they are migrating,
so I'm not concerned. Other internal lists are just hold overs
from the closed cathedral
days. Trying to close these closed lists is somewhat challenging, too.
serve only to distract people from the openness of the project, and
they keep the
conversation fragmented. So, if a conversation is not
confidential, get it out in the open. If it is confidential, keep it on
a properly marked internal list and keep the number of people on that
list small. I have zero interest on being on confidential lists, by the
8. Transparency increases speed in
most cases because it shines a light
on internal politics.
Some people are concerned that dealing with large numbers of
developers and users in a community will slow things down. All that
extra email! This may
happen initially, but in many instances transparency actually increases
the speed at which things can operate. This is
anti-intuitive, but I'm convinced it's true if you give it a chance.
Perhaps it's because transparency reduces the internal politics by
shining a light on the trivial things we sometimes focus on.
Perhaps the openness naturally attracts the people who are specifically
interested in a given project, so you weed out the non-performers
offending anyone. I don't know. All I know is that for my
activities, working in the open is faster and it's not even close.
NOTE: This issue fascinates me more than any other in this list. I'd especially
to hear about what you have experienced.
9. Make core governance and
development decisions before opening even
if you have not fully implemented the system.
We didn't launch with a lot of initial infrastructure
for co-development, which made things somewhat
difficult for the non-Sun community members. However, external
can search the bug database, report bugs, offer fixes, and request
sponsors to putback that code. And they are
Which is great. And more is coming, obviously. But the point is to
think these things through (remember: the code is the most important
part of the project) before opening, so you can lead strongly through
the implementation process when you are open. We have been planning for
all along. We specifically wanted the broader, post-pilot community
involved in the decisions since the pilot community was small (by
necessity). We set up the
Advisory Board (CAB)
to develop an OpenSolaris Charter
(both currently drafts on the CAB's open list),
and there's an internal team (with three CAB members participating)
specifying the actual co-development infrastructure. People want this
part of the project to move faster (and we do, too). We hear you.
This issue is also important because you want to know what kind of
to build. Some people asked me really early in the project -- like
pre-pilot early -- what the OpenSolaris community would look
like. They asked for a prediction, basically. Yah, right. They'd ask
over and over again -- before
we had a license, before
we had business model, before
we had a CAB, before
we had a Charter and Governance, before
we had a
co-development plan. Nice, eh? I ignored them, basically. I simply just
keep on saying that we are transforming the
Solaris market into a community, and that community would consist of
Solaris developers, system administrators, and users from Sun's
customers, ISVs, and partners. That's your community. The key, however,
engage, build, and grow that
community. To answer that question you have to also answer the
governance, license, business model, and infrastructure questions. They
are quite directly linked.
10. The conversation is the
It's best to not market to a community from the outside by
shouting "messages" at people. Instead, marketers should join the
community and participate in
the marketing process with the community as co-equals. I think we've
done a pretty good job on this one for a corporation. We had a pretty
with more than 150 Solaris engineers blogging personal tours through
their code, and there were dozens
and dozens of community blogs that lit up on launch day as well. We've
been open about our intentions to open Solaris all along, too. Yes,
a press conference (pretty traditional), but we had engineers meet the
press along with the
executives (an improvement). There was no formal press release with
quotes, though. Instead, PR sent out
what they call a "media advisory" and we tried to keep their
pre-briefings down to an absolute minimum. We wanted the blogs to lead,
we wanted the code to lead, we wanted the community to lead. For a
year, I had advocated no launch at
all. I just wanted to open the site when the code was ready, and, well,
that's it. The community is already well connected on list and via
besides, no one would expect that from Sun, right? Some (read: most)
people thought I was
nuts, of course, but I had no time for a traditional
marketing/PR-driven launch on this project.
came up with the
idea of a blog launch. OpenSolaris would be launched on blog.sun.com.
So, he sold it and went about driving it with Liane
. It worked out great, and
I'd argue that the
OpenSolaris launch was the single most credible thing Sun has done for
developers since I've been at the company. Ok, I'm biased but
whatever. So, if
you want to do
marketing on an open source project, go Cluetrain
and join the
11. Credibility and reputation grow
from involvement, humility, work,
and code – not talk.
We did a lot of talking leading up to the opening of Solaris.
actually. I'm glad we were open about our intentions, and we did get
some credibility for opening our conversations in the press and in our
blogs. But I would have been more comfortable had we launched a little
earlier or cut the chat a little along the way. I also think we
sometimes confused corporate competitive issues with community building
issues. I know I surely did. Also, for a very long time we
didn't have much to show; we were running a closed, NDA pilot. It
wasn't a real big
deal in the end because we knew the code was coming, but if I had to do
over again ... well, I'd tone it down
12. Focus the project goal and
strategy on the
opportunity to do something great,
not on trying to solve issues common to all products.
Having a strong, clear goal is the way to go. We sometimes
churned with lots of little goals that were all good but pretty typical
for a corporation. This is one area I
think we could have involved the pilot community more. To me, I see the
goal for OpenSolaris as being the perfect opportunity to build a
community around some really amazing code. Everything grows from that.
And I see three groups directly involved: (1) The Sun executives want
to expand the Solaris market, drive Solaris into new markets, and sell
more systems and services. (2) The Solaris engineers want to engage
developers outside the company, share code, and improve an already
great system. And (3) the Solaris market/community wants to see the
code, optimize applications, contribute to Solaris development, and
create ports and distributions of their own. The strategy for all this
involves transforming the current Solaris market into the new
OpenSolaris community. Sun is opening up and engaging the Solaris
community (developers, sys admins, customers, ISVs, partners,
universities, users ...), and we are quite literally
enfranchising that community with an open source license, a governance
based on merit, and a new co-development infrastructure. I'm trying to
put all that into one sentence. :)
13. Be prepared to lead.
Leadership is just as important in community building as it is
corporate or government structure. It manifests very differently
though. In communities, power seems to be distributed among the people
who have earned the credibility because they have done the work. And
since these people work transparently everyone knows what they've done.
This is not
always true in a traditional environment. Also, what I like
about the culture of leadership within a community is that leading,
following, and learning seem to mix pretty seamlessly. And
endless amount of opportunity for those who are willing to work their
way up to a leadership position.
14. Don't manage the community like
it's just another project. It's not.
A community is special. Treat it that way. Actually, you'll have
since it's not "your" community. Unlike an internal project, you are
not paying your community, so you'll have to lead by example. And it's
impossible to "manage" a community, so, again,
the only way is for managers to join and participate. Manages may have
seniority internally, but they
have to earn their way externally within the paradigm of the community.
15. There's no substitution for
You can't fake this, so don't try. You are either part of the
community and contribute, or you are on the
outside looking in. Give it a try. Join the community. Be humble.
Learn. Lead in your area of expertise, defer in areas where others are
more knowledgeable, and earn
like everyone else. Trust that someone else will be
leading the things
that you are not.