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, 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 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 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
  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. 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 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.

  8. 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.

  9. 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.

  10. 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.

  11. 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.

  12. 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.

  13. 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.

  14. 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. 

  15. 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 21, 2007 at 11:02 PM 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 04:38 AM 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 08:40 AM JST #

[Trackback] Jim Grisanzio summarized his lessons in building open solaris communites: Building OpenSolaris Communities. An excellent read.

Posted by on December 27, 2007 at 10:23 AM JST #

[Trackback] 二重になりたいという方は、プチ整形を検討されてはいかがでしょうか。仕上がりが不安かもしれませんが、いたって自然で生まれつきの・・・

Posted by 醤油飲み大将 on August 30, 2008 at 03: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 07, 2008 at 09:15 PM 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 09:29 AM 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 02:10 AM JST #

Post a Comment:
Comments are closed for this entry.


« August 2016

No bookmarks in folder