Building OpenSolaris Communities
OpenSolaris is a community of communities, and building those
communities takes time and effort. No way around it. Throwing code over
the wall and walking away is a lost opportunity to engage developers
and users
around the world. Currently, the biggest OpenSolaris community lives on
opensolaris.org, but even that community is now made up of many smaller
communities in the form of Community Groups, Projects, and User Groups.
And then there are other nascent communities starting up with websites
in emerging markets and even entire distributions that don't
necessarily have direct connections to the operations on
opensolaris.org. OpenSolaris is no longer monolithic and based on one geography. It's growing and
diversifying globally.
As Sun moves closed development projects to the open on opensolaris.org or just starts new projects from scratch in the open, many people ask, "How do we build a community?" and/or "Why should we build a community?" and/or "How do we grow?" Well, here's my shot at answering those questions from a non-technical perspective. The list of issues below is not necessarily comprehensive (and we don't necessarily do some of these things particularly well), but it's just a set of issues to consider if you want to build a community of people around your stuff.
Building a Community
OpenSolaris References:
Constitution | Community Groups | Projects | Website lead reference | Contributing | Values | Development Process | Development Reference | Advocacy & User Groups | Code Contributors
Books on Open Source, Licensing, and Community Development:
The Cathedral and the Bazaar Eric Raymond | Innovation Happens Elsewhere Ron Goldman, Richard P. Gabriel | Open Source & Free Software Licensing Andrew M. St. Laurent | Open Source Licensing: Software Freedom & Intellectual Property Law Lawrence Rosen | Open Sources: Voices from the Open Source Revolution Oreilly | Open Sources 2.0 The Continuing Evolution Oreilly | Free as in Freedom Richard Stallman
Post updated: 12/26/07, 12/27/07, 4/28/08, 5/16/08
As Sun moves closed development projects to the open on opensolaris.org or just starts new projects from scratch in the open, many people ask, "How do we build a community?" and/or "Why should we build a community?" and/or "How do we grow?" Well, here's my shot at answering those questions from a non-technical perspective. The list of issues below is not necessarily comprehensive (and we don't necessarily do some of these things particularly well), but it's just a set of issues to consider if you want to build a community of people around your stuff.
Building a Community
- Planning & Building:
The first thing to realize is that building a community is an active and cyclical process of
planning and implementation. Some people balk at that notion. They
believe communities ought to grow organically. But I suspect
most communities actually grow based on active participants directly
engaging new people and managing resources from diverse sources
including corporate, foundation, and individual. Also, I believe
the concept of community building is based largely on two simple
principles: (1) open
communications and (2) open development. Basically, working in the open
and
talking in the open. And if you really want to grow big,
you'll need to do three things really well: (1) talk to a lot of
people all the time, (2) include them in your work, and (3) provide
ways
for them to contribute back by creating and sharing their work with
others. Then the process of working itself helps
build community because it generates more communications and more work.
And around you go. But active building starts with a plan. Write one.
Then start building. Then update your plan. Repeat.
- Transparency:
Get outside. You can't build a community from
behind a firewall. Conversations, lists, source code, binaries,
documentation, tools, people, infrastructure, artwork -- get it outside
so
everyone has a fair shot at engaging and contributing. If there is
nothing to gather around, then no one will
gather and you will not have a community. And if you are only talking inside, no one on the outside will know you even
exist. This is the single biggest mistake people at Sun make. They try
to live in two worlds. You can't. Decide. Are you open or not.
- Participation:
Communities are about direct participation and the building of trust relationships. That
means people earn their way based on their contributions, and there is
an expectation of opportunity and openness. You can also look at this
issue as the distinction between a community and a program. Most
programs are one way -- usually going from a company to a market. But
communities are two ways (many ways, actually), and involve just as
much coming in as going out. Also, participation is really about doing,
not talking. Those who do get to lead, and those are the people whose
voice is heard above all others. You earn your credibility based on the
work you contribute to the community, not the title you have from your
company. If you want people to stick around, you will have to embrace this concept and enable them to participate.
- Contributions:
Define
the contributions you are looking for. Give general categories and
specific examples and expect the community to offer more
examples and things you hadn't even thought of (that's the goal,
actually). Here is a list of contributions that OpenSolaris community
members have been involved with -- code, scripts, tests, help,
presentations, user groups, conference management, language portals,
translations, university courses, graphics, ads, training materials,
screencasts, videos, websites, wikis, evangelism, documentation,
articles,
blogs,
podcasts, development process, tutorials, input methods, feedback,
language compression tools, SCM tools, re-writing closed binaries,
defect
tracking system, shells, distributions, books, ports, governance.
Etc. Although many of those items are technical, some are not, and most
do not involve kernel code. In other words, think about a variety of
contributions you want to encourage, and then let that list grow in the
open. Then when things start coming in, point out the people who are
contributing. You want to always call attention to contributions, but do
so in an understated way. In most communities, everyone knows who is
really contributing because work speaks louder than words, and the
contributors are generally working with each other in the open. But it
doesn't hurt to thank people once and a while.
- Presentations:
The biggest problem with most technical
presentations is that they are painfully long, and they focus too much
on describing the technology itself. That's fine for a classroom or an
interactive tutorial session. But the act of building a community is
actually not about technology. It's about people. So, explain your
technology, sure, but
focus much more on how developers and users can get involved and
contribute to the
technology and community and how that benefits everyone. Most technical
presentations have one
slide at the end with a list of lists
to
join. That's not enough. It can't be an after thought. Make it core.
- Conferences:
You
have to go to conferences. Sun runs various
conferences, but you need to go to non-Sun FOSS events as well. Both
have value but both are different. Also, don't feel you have to
always present at conferences. Participating in the sessions,
hallway conversations, BOFs, and parties is just as important as
presenting formal papers. Just being there is critical. You'll need a
mix of face-to-face and online interactions to create a feeling of
community. But don't miss the opportunity to do a rapid-fire
lightning talk! Most good conferences offer these opportunities. And
add
user groups to your list of conferences. Go to them and/or start
them. If you start a user group, do it in a bar or cafe or something.
Start small and social, and let the technical presentations grow slowly
as more people bring their own experiences to the group. And don't feel
you have to always have a big technical presentation with a 100 people
in the room each month. That's not realistic. Maybe try
technical sessions quarterly but meet monthly in a bar for food and
beer and then discuss things on a mailing list in between meetings.
Start small and look for ways to build tradition through repeated
experiences. Over time a little culture will soon develop, and that is
the glue that will
hold your user group together.
- Development
Process and Infrastructure:
If you are going
to build a community, you ought to spend some time figuring out the
physical infrastructure you'll need to support all the people you want. Will
it
scale? What development process is needed for accepting contributions?
What testing is needed? Do you offer a sandbox for experimentation?
What
tools are necessary to host the project's artifacts? Who has access? This all
depends if you want to host on opensolaris.org or on another site, and
whether you are running a community group, a user group, or
a development project. The higher end code contributors will always be
small in number, and those are the guys who have to figure out the
tools they'll need. However, non-coders should be involved in these
discussions at least partially, so that your infrastructure is built to
accommodate a wide variety of contributions.
- Leadership, Governance,
Culture:
What are your community's values? What will the social structure
look like? How will your community run
itself? How will you make decisions? What is your leadership model? How
will you call attention to
contributors? How do you resolve conflicts? These are questions that
need addressing whenever any
large group of people comes together to collaborate around anything.
When you are small, you can manage this easily in your head, but when
you grow globally you need to document the behavior you want to
encourage and set some rules around how to manage it all. It doesn't
have to be all pervasive and bureaucratic, but people need to know what
you stand for and what you expect. Perhaps a
single strong leader is appropriate, but you may want
to consider other
options of distributed leadership mechanisms as well. Look at other communities such as Mozilla, Linux,
Apache, Ruby, Java and the BSDs for examples. Actually, there are many others, but
those are some of the bigger open source software communities.
- Universities: If
you want to grow, you need to go back to school
and hang out with young people. Get your project in front of students
and professors at
universities in emerging markets first. Start with India and China for
obvious
reasons. But don't
neglect the established markets as well. University visits are
probably the single best way to ensure that your project has a shot at
surviving the future. Neglecting universities is not an option. It
needs to be a top priority. By the way, this will probably be the most fun part of your community building operations.
- Global: Build
your community with a global perspective in mind.
Where are the developers who would be interested in your stuff? Go
there. A lot. When you go global, though, you will run into all sorts
of interesting language and cultural issues that will slow you down.
Expect it. Look for people who can help build the community in a given
location, and then work to connect multiple locations together. You will
not
have "one" community around the world, so don't expect everyone to just
follow you (or even understand you). You will have many
communities,
and they will express their own independence quite differently. Your job is
to encourage them to be as independent as necessary, but also to help
them connect to other regions so they can participate in the meta
community. This is not easy, by the way. But it's necessary. And it can
be a source of really innovative contributions as emerging markets
develop.
- Marketing:
Get
to know your marketing people. They can help
publicize your project formally at conferences or within press/analyst
operations or at customer meetings. And they can offer a
perspective you may have not considered on important issues, such as
trademarks, branding, launches, announcements, leaks, and market
disruptions. You don't necessarily know what the
press is saying about you, right? Would more exposure help?
What are the competitive issues marketing sees that you don't? Also,
participate in special programs Sun occasionally runs, such as coding
contests and events. Sun has other
developer
programs and web sites that all welcome content and participation.
Leverage the company's global resources this way. By the
way, humility and honesty are the best techniques for doing effective
open source marketing. Keep that in mind as you publicize your stuff.
- Advocacy: This
is much bigger than marketing and it's somewhat different as well. This
is not about specific marketing disciplines such as advertising,
marketing, branding, PR, or AR. Instead, it's about direct, unfiltered
engagement at a level
that leads to active participation and contribution. It's about
community building via open communications. Now, that includes marketing, sure, but it also
includes
engineering and project managers -- and anyone else
who wants to get involved. Also, you
are the best advocate for your work. So you need to
assume the direct responsibility of communicating in
your
own
way. You will be leveraging other resources for this, but
ultimately you are
responsible for your own bottom line -- which in this case means
growing your community and advocating your technology. Don't just give
this function to someone and walk away. Be involved.
- Legal Issues:
This is mostly internal to Sun as you open previously closed
code and tools. But even when you are open, you need to consider trademarks,
copyright, contributor agreements, licensing, source analysis, etc.
These things
will not
necessarily help your community grow, but they can certainly stop
things jet fast if you don't consider them at all. Get to know your
lawyers. Teach them about the needs of the community, and ask them to
teach you the realities of the law. The education here should go both ways.
- Project Management: As your community grows, it will surely contain
multiple engineering projects and user activities around the world. Who
will run these complex operations? Who will manage the plan and keep
the metrics and roadmaps updated? Who will alert you to the
organizational politics that you will surely encounter? So, you
may want to hunt around for a good project manager to
help
facilitate things. Just as engineers should build community in the
open, so too should project managers. If you look at your project in
the
broadest possible context, you'll see that it touches many diverse
disciplines both inside and outside the firewall, and that will affect
how you build your community.
- Have Fun:
And finally, building a community is ultimately a social exercise, so people should
have fun as they participate. You want to draw people to your community, right? You want
to encourage people to stick around, right? Make it fun to hang out.
Give people the opportunity to have fun and they will.
OpenSolaris References:
Constitution | Community Groups | Projects | Website lead reference | Contributing | Values | Development Process | Development Reference | Advocacy & User Groups | Code Contributors
Books on Open Source, Licensing, and Community Development:
The Cathedral and the Bazaar Eric Raymond | Innovation Happens Elsewhere Ron Goldman, Richard P. Gabriel | Open Source & Free Software Licensing Andrew M. St. Laurent | Open Source Licensing: Software Freedom & Intellectual Property Law Lawrence Rosen | Open Sources: Voices from the Open Source Revolution Oreilly | Open Sources 2.0 The Continuing Evolution Oreilly | Free as in Freedom Richard Stallman
Post updated: 12/26/07, 12/27/07, 4/28/08, 5/16/08
Great blog post Jim. I'd add one very important key factor. Have fun. We do *such* a bad job generally at keeping it fun in OpenSolaris, yet it's one of the most important things to maintain.
Posted by Glynn Foster on December 22, 2007 at 07:02 AM JST #
hey, Glynn, *very* good point. I'll add it to the next draft for sure. :)
Posted by Jim Grisanzio on December 22, 2007 at 12:38 PM JST #
Your thoughts are gold. Your adding a little sunshine to the world.. Your thoughts on the male Japanese phyche.. wow..
Posted by GerwingR on December 23, 2007 at 04:40 PM JST #
Posted by c0t0d0s0.org on December 27, 2007 at 06:23 PM JST #
Posted by 醤油飲み大将 on August 30, 2008 at 10:02 PM JST #
I was looking for general reference about building comunities when I came across this post. It's an excellent summary, much appreciated. Thanks.
Posted by Robert Fekete on December 08, 2008 at 05:15 AM JST #
We all like you for your experience and transparency Jim, but I now realize why we all implicitly trust you to do the right thing for the community.
I was wondering how to use the limited time on my hands for effective Belenix work, and your blog post will stand as a good guideline.
-- Sriram
Posted by Sriram Narayanan on December 21, 2008 at 05:29 PM JST #
Thanks, Sriram. That`s very kind. :) And to your point about limited time, I couldn`t agree more. We all have limited time, and we all have to focus as much as possible. That`s what I`m trying to get at with this post. Stick to the basics ...
Posted by Jim Grisanzio on December 22, 2008 at 10:10 AM JST #