Email
Like
Liked ×
Save
Private Content
Embed
Loading embed code…
We have emailed the verification/download link to "".
Login to your email and click the link to download the file directly.

To request the link at a different email address, update it here. Close
Validation messages. Success message. Fail message.

Check your bulk/spam folders if you can't find our mail.
Loading

+ Follow

Cultivating Community: How to Make Your Project Blossom

by Leslie Hawthorn

1,634 views

This opening keynote address was delivered at the Berlin Buzzwords 2012 conference. Video is available at http://vimeo.com/43759727 ...

This opening keynote address was delivered at the Berlin Buzzwords 2012 conference. Video is available at http://vimeo.com/43759727

This talk focuses on community and open source software projects: what it is, what it isn't, how to make your project most welcoming to newcomers and how to build communities that last. In this talk, Leslie Hawthorn draws on the observations she's made after working with hundreds of FOSS projects, sharing community building best practices with the audience. Leslie also discusses a few of her favorite FOSS projects who've built tremendously successful communities as case studies for "community management done right.

This talk is available for remixing under a Creative Commons license and speaker notes are included in the file.

Accessibility

View text version

Upload Details

Uploaded via SlideShare as OpenOffice

Usage Rights

File a copyright complaint

2 Embeds 10

http://us-w1.rockmelt.com	9
http://www.mefeedia.com	1

Statistics

Likes: 3
Downloads: 4
Comments: 0
Embed Views: 10
Views on SlideShare: 1,624
Total Views: 1,634

Many thanks to audience, program committee & organizing team Introducing myself: From Portland, Oregon Six year career in open source spanning academia to industry; Google Summer of Code, Google Code In, OSU OSL and now Red Hat Focus on community management, mentorship, onboarding new contributors and helping teams get things done
A brief overivew of what we’ll be discussing today. I’ll be presenting an overview of community – a bit about what community is and what it is not, then diving into best practices to make your community healthy, vibrant and growing as it should. Finally, we’ll conclude with a brief case study of an open source project I feel really does community quite well and what has made it such a success.
problematic it can be to define community. In just the past few years, I’ve personally seen a proliferation of the things people call community, from Facebook groups to Tweetups to citizen groups who repair their own streets. Community means many things depending on who you are, where you grew up and your personal value system. For some, their neighbors are the first thing they think when they hear the word community, for others it is a social club or a group they volunteer for or even just their close friends. As all these definitions show, community can be about place, faith, common background or common values.
With an eye to definition 3, an occupational group affiliation starting with “the” .... When it comes to open source, I find community can particularly difficult to define. We know that open source folk have open code bases that are shared globally, but there’s no one true code base or even programming language or tool chain that defines the open source community. Even the point that the open source community shares code fails to highlight the many other contributions that make an open source project work: documentation, QA and testing, user experience design, etc. When we speak of a common value system, that too is difficult to pin down when it comes to open source – are you a believe in software freedom or open source? Are the values held in common in your community just about code or something more, such as for a social justice project? As we all know, many contributors are paid to work on open source projects and this trend has been ever increasing with increasing corporate investment in FOSS, so we can no longer define ourselves as an army of volunteers. Perhaps the one tie that binds together “the” open source community is our desire to scratch our own itch.
Perhaps we can settle on the essence of community – a group of people working together for a common goal. However, the story isn’t quite so simple – even within a single community, there can be a plethora of personal goals and motivations that must be rationalized individually and as a group in order to achieve common goals. What helps a community rationalize these personal and group dynamics in the quest to achieve a common goal?
With an eye back to definition 4, a group of associated nations sharing common interests or a common heritage, the literal sharing of common heritage is a key means to help your community work towards common goals. Sharing the stories of how things came to be a certain way in your project makes newcomers feel welcome and truly included. Further, sharing stories strengthens bonds between people, and free software projects are no different in this regard. By sharing the common history of the project, all community members are not only well informed about how things are done and why they are done a certain way, but are themselves included in the story simply by hearing or telling it. Being a part of the story motivates people to shape the tale in whatever way makes sense for them, in turn motivating them to keep sharing the group’s common story with themselves as a participant.
So, we’ve talked about sharing common stories and, as we all know, a particular open source community will share common tools: a version control system, a wiki, mailing lists, etc. I do want to take a moment to consider a trend that I find to be suboptimal, namely the conflating of a particular tool with a community. I’ve talked to folks who are particularly insistent that a particular Facebook group is a community and that strikes me as a strange way to view community. Facebook is a tool, not a community. Never forget that your community is made up of the individuals in it, not the tools you use to communicate or accomplish your tasks. This tip can be very helpful to bear in mind should you be having a contentious discussion about which forum software to use or which version control system is really best. Keep the focus on the individuals and their needs to be successful, not on the tool chain.
All of that being said, tools are very much a guide to the communities that use them. For example in this picture versus the last one, we can assume that the folks who laid all their tools out on a picnic table in an orderly fashion either never use these tools – possible – or that they take their craft very seriously and keep their tools in great working order. Contrast with this example – the tools are rusty and covered in dirt. Perhaps we’re dealing with a careless gardener? Remember that the tools a community uses tell you a lot about that community, from heritage to workflow. Addicted to your inbox? You might find that a community that communicates entirely through forums isn’t the best location for you. Found a project using CVS for version control? That project has likely been around for a long time, meaning their code base is likely more complex and may not be the best first point of contribution for an open source newbie. When examining a community, take a look at the tools it uses and how it uses them – both are excellent guides to a community’s personality and processes, making it easier to tell if a community is right for you. For folks in well established communities, considering what your tool choices say about you is a useful thought exercise if you want to bring on new contributors and can be useful as a means to identify items for project housekeeping.
When doing that work of introspection about your project’s tools, processes, lore and more, it’s worth taking stock of just how diverse your community is. We think of open source communities as being globally distributed – many time zones, many native languages, many types of talent and many different motivations. It’s important to note that thriving communities are not homogeneous – they have contributors with many different skill levels, types of skills, etc. If you examine your community and find it’s not as diverse as you would like it to be, consider taking steps to change it. It could be as simple as inviting people directly to join your community, or it could be fun to start a program to bring in new folks from various walks of life.The more diverse your community is, the stronger it is – more hands to do the work and more perspectives to examine solutions to problems to ensure the best one is chosen.
In thinking about how to define community, I was particularly struck by the simile of community as a garden – a place where many different parts make up a much greater whole. In exploring best practices for community, we’ll walk through them using the Community as a Garden lens, drawing parallels between growing community and growing plants.
When we think of model communities, they just make working together look easy . Some folks are employed full-time to work on community management, myself included, and great community managers tend to make the work of getting teams to work together look easy . The fact is, having a strong community takes a lot of work. Good communities are cultivated and require constant tending, from making sure your members are able to get together for sprints either in person or online, to taking charge of inviting folks you think would be excited to work on your project to join up, to spreading the word about your project’s latest release and new key features. Great communities don’t occur by accident, they are the product of diligent, ongoing work. There’s an effort by a team of contributors at my employer, Red Hat, to capture some fundamental lessons of community cultivation called the Open Source Way – check it out and please contrib ute!
As we’re considering how to best cultivate community, I’ll step through a few best practices based on my experiences working with hundreds of open source projects. These projects varied widely, from some with just a handful of maintainers to others with hundreds of developers. Across each of these projects, these best practices have been universally useful from my experience. YMMV. One of the most important aspects of growing one’s community well is to define the landscape – set a clear mission statement and stick to it. Providing such a mission statement really helps folks to know what your goals and non-goals are, and it can be helpful to quell non-productive debate by pointing back to the goals and non-goals explicit in your mission statement, Subversion a compelling replacement for CVS example.
While you may have been a resident of your particular project community for a long time, it’s very helpful to asses your project from the new comers perspective. People who are new to a project are your greatest asset – they are the people who know everything you’ve forgotten because it is now second nature to you, as familiar to you as the pathway to your own front door. Consider, for example, how welcoming your project is to new people. Are conversations in your forums civil and productive? Does banter in the IRC channel stay kind and on-topic? Do posts to your mailing lists show that project members are eager to help point to a reference or do you suggest that folks RTFM? If you’re failing to make your project more welcoming, you’re losing out on users who may be your most passionate evangelists, and on bringing additional contributors into the fold. An excellent example of a community that does this well is the OpenMRS project. Their about page contains their mission statement, locations of their developers, they always have someone in channel to answer questions, they focus on implementers and users in an equal fashion to developers and their project’s discourse is incredibly civil.
Once you’ve determined if the tone of your community is welcoming, it’s time to make sure that all paths to success are clearly demarcated. Are your collaboration resources clearly linked from your home page? If someone can’t find your mailing list to ask a question or get involved, they’re not going to participate. If you reject someone’s first patch for style reasons but have no clearly published coding guidelines to refer them to, you’re more likely to lose both the good work done in the patch and the future good work that contributor would do. Does your about page contain that clearly articulated mission statement? Do you have a community manager or other individuals who act as a welcome wagon, pointing folks to the right resources they need to get started or keep moving? Is it obvious where you can download the source code? If not, the community’s hard work simply won’t be used. The Dreamwidth project is an excellent example of this – they have a dedicated “welcome wagon” to help new people get started, all patches are publicly celebrated in the IRC and no first patch is rejected due to style guidelines. IIRC, the commiter walks the new developer through the changes to the patch, then it is committed.
While you’re doing that work to assess the paths to success in your community, consider that you’re going to need help doing so. Remember, your newbies are the ones who know everything you’ve forgotten, like the fact that there’s no style guide, which is meaningless to senior contributors who already know how to get things done. If you’ve already done the work to make sure new folks can get involved with a minimum of barrier to entry, it’s not enough to have simply built a compelling code base and contribution infrastructure. You need to explicitly invite people to join in your work, using tools like a strong call to action on your home page - “Join Us to Make Foo Project Better! - and, even better, personal invitations to participate, along with explicit tasks, to people you’d like to see as contributors. Nothing gets someone more excited about improving a project than being told “We really need such and such done, and given your skills and inter ests I think this work would be a perfect fit for you. It’s also worth including a diversity statement as a way to invite folks to your community – Dreamwidth again.
So, you’ve made sure that your community is welcoming, paths to success are clear and that you’re actively asking folks for help in specific ways. All of these things are wonderful, but they’re not enough to keep the community garden humming healthily. We have likely all heard horror stories about trolls and poisonous people in communities. Sadly, trolls and poisonous people are often allowed to continue to damage a community because people tend to avoid confrontation or just don’t know how to handle the problem. Without removing these weeds from your garden, your community will have fewer of the resources it needs to grow. Poisonous people can be energy and productivity vampires in just the same way that weeds take vital nutrients that your garden needs to thrive. Take care of these problems early and often, as tolerating bad behavior simply sets a precedent that bad behavior is tolerated in your community. When you see trolling start, quash it quickly. Sometimes, people can be unaware that their behavior is harmful – example of the person who replied to every post in Subversion project. Ask poisonous people to continue their quest elsewhere as soon as their poison starts to seep into your community’s soil.
Speaking of how important it is to pull weeds at the beginning, consider the impact of weeds on seedlings, the smallest and most tender plants. Weeds can choke out seedlings and cause them to die off. In much the same way, trolls and poisonous people who are known in a particular community tend to latch on to new folks who don’t yet know about the problems they create. In fact, trolls can sometimes be the most welcoming and attentive folks in your forums or IRC channel. In addition to protecting your seedling contributors from pests, they’ll require extra tending – more pointers to resources, more time to answer questions, more time socializing to feel welcome, included and motivated. It’s well worth making time to do this nurturing for the sake of your community’s health and growth. Another project that does an excellent job at this are the Drupal folks. They have a ton of resources specifically for new contributors, including the Drupal Dojo, community “barn raisings” and mor e.
For those not familiar with the term, companion planting is the practice of planting certain types of plants with one another in order to make the garden grow most successfully. In this picture, for example, the marigolds repel pests that would quickly consume the tender chard. Companion planting works equally well in your community garden. When considering how to help community members grow their skill sets and responsibilities, who they are paired with as a mentor or helper is very important. Is the person an auditory learner? Pair them with someone who likes to communicate via voice. Are you an expert on a particular topic but a less than patient teacher? Find someone who you communicate well with who can act as a well qualified instructor and be available to that instructor as a resource while they exercise their teaching skills. Everyone in this scenario thrives. One of the key traits open source projects that did well in Google Summer of Code had was this ability to effectively companion plant – well matched mentees felt more invested in their projects, were more likely to stick around longer and were willing to pay out of pocket to attend developer conferences so they could meet their mentors and other project members.
An essential activity in any garden is pruning and trimming – cutting back old growth stimulates many plants to sprout new growth much moreso than if the pruning had not occurred. This same concept applies to communities. As projects grow, there comes a tipping point where the new folks far outnumber the original contributors, and it can be easy for there to be discord between those who want things to continue as they are and those who see different ways to approach matters of business, marketing and code creation. Old timers can tend to leave a project as this shift occurs, and it’s important to realize that this progression is OK and natural. Even more important is the opportunity for introspection if you are one of the old guard in a particular project. Are you still passionate about it? Do you feel comfortable with changes to project processes or do you only feel comfortable with status quo? How important is it to you to remain invovled? By actively owning your own pruning processes, you ensure that you continue to thrive by moving on from past endeavors that no longer suit you, while ensuring your project thrives as new ideas take root and new methods blossom.
We’ve reviewed a few best practices for making your community garden healthy, from making sure paths to use and contribute to your project are clear to nurturing your newbies. We’ve covered a lot of ground and, likely, many in the audience have heard these messages before today. The significant take away from these messages, in addition to following the best practices, is that creating a healthy community takes hard work, many different types of tools and many hands to tend the garden. As I mentioned previously, healthy communities do not happen by accident but through careful tending – hard work, but rewarding to be sure.
We’ve stepped through what community is, what it is not and several best practices to make your community thrive. I’d now like to take the opportunity to introduce you folks to a project near and dear to my heart as a case study in community management done right, or how to make your project blossom.
OpenMRS = open medical records system The project was started by a group of research physicians at Indiana University with strong ties to providing medical care in Africa via their families previous work in this regard. The project started as a way to help doctors provide accurate medical data to their governments since foreign aid, most especially for HIV, depends upon the number of reported cases of infection. In many cases, these records were/are kept on paper, making reporting difficult if not impossible when such records are destroyed by water, fire, insect damage, etc. In addition to their social good mission, OpenMRS’ team has done great work in pushing standards and interoperability for various electronic health care records, most notably their support for standardizing on the HL-7 protocol for medical record transmission. Further, the project leadership has worked extensively to create economic development opportunities in the communities of HIV patients they serve in Africa, culminating in a government sponsored course to train OpenMRS developers in Rwanda, with other African nations set to follow suit.
In the five or so years I’ve been tracking this project, growth has been simply phenomenal. What you’re observing in these two photos is the delta between just two years – 2009 when I attended their annual implementers meeting – and the last one in 2011. IN that time, the project has swelled to many hundreds of new users and contributors, including a ‘reimportation’ of the code base to the United States where it has been deployed in several clinics ministering to low income and at risk populations.
Set explicit goals and non-goals, an important non-goal being not interested in creating a commercial product, though others were welcome and encouraged to base their livelihoods on the code base. Strong focus on usability since those working with the software are often in adverse conditions with regard to connectivity, power, etc. Making it easy for them to use the software and having a strong community support model reinforced that it was a worthwhile endeavor to use OpenMRS even when it was challenging to do so. Last but not least, I was most impressed with the value placed on sharing knowledge. One of the most in-depth conversations I had with the project leads very early on was what the best possible wiki software, bug trackers, etc. would be for their community. And I keep getting these kinds of calls as well as the explicit sharing of knowledge these folks have gained from other open source people with knowledge to share. The virtuous circle has truly paid off for OpenMRS – more developers, more users and better health care for the world’s poorest individuals.
We’ve talked about how to define community, best practices to encourage community health and growth and we’ve explored one particular project’s success in growing its community. I hope that this journey has been useful for each of you, and I’d like to leave you with this parting thought... I clearly have strong ideas about what makes a community work well and no doubt many of you in the audience do, too. While we’re busy implementing these best practices in our communities, I want us all to remember to come into things with new comers eyes as much as possible, to be ready to be surprised and to innovate when our existing processes no longer serve us and the needs of our community. Beautiful gardens can grow in the most unlikely places, just as we can grow and thrive along with our communities provided we are ready to take the lessons whereever we may find them.

3 Likes

Gail Zahtz, Founder and CEO at A Life Guide Institute 3 months ago
manojkumrm 1 year ago
Ingo Renner, TYPO3 Core Developer, Release Manager TYPO3 4.2 at ingo-renner.com 1 year ago