Friday Dec 21, 2007

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. It's growing and diversifying.

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 particularly well), but it's just a set of things 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 this is an active 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 if you are talking inside, no one 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.

  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 fully 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 even 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 work, 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 think 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 tutorial. 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 out on the opportunity to do a rapid-fire lightning talk! Most good conferences offer these opportunities. Add user groups to your list of conferences, too. 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 monthly technical presentation. 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. Look for ways to build tradition and repeated experiences. If you do that, 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 structure 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? 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 our 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 choose and 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 expect. Perhaps a single strong leader is appropriate and all you need, but you may want to consider other options as well. Look at other communities such as Mozilla, Linux, Apache, 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 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.

  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 locals together. You will not have "one" community around the world, so don't expect everyone to just follow you (or even understand you initially). You will have many communities, and they will express their own independence. 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 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. Now, that includes marketing, sure, but it also includes engineering, project management, and communications -- 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 your own stuff 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. 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.

  14. Have Fun: Building a community is ultimately a social exercise, so people should have fun as they contribute to the community. 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.

  15. Project Management: And lastly, 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 to 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. 

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

Posted: Dec 21, 2007

Permanent link to this entry | Comments [4]

This blog copyright 2008 by jimgris