Current Articles | RSS Feed
There's a lot to like about open source software. It can help your business by cutting costs and producing better software. It's open, auditable, and customizable, and free of the restrictive, invasive licenses and EULAs that infest proprietary software. You can build a community around an open source project, one that incorporates contributions from both staff and outside developers. If you're wondering how to start up and manage a genuine open source project, here are four fundamental tasks to get you started: start small, build trust and social capital, start smart, and build for the future.
Before you start, you should be aware of some fundamental FOSS concepts. For instance, Free Software and open source software are not the same, though there is considerable overlap. Think of Free Software as being a social movement fueled by ethics, while open source is a development methodology. You don't have to take sides; the important bit is to do some reading and develop a good understanding of the two philosophies, because they matter to many FOSS developers and users.
It is equally important to understand licensing issues and to respect FOSS licenses. It is a mistake to think of FOSS proponents as unsophisticated, or as a bunch of lone nerds coding in their parent's basements. The FOSS world has some of the smartest people in tech, and the best projects are disciplined, organized, and legally savvy.
Before launching your own open source project, consider contributing to an existing project, because that's a great way to learn the ropes. Pick something that you use every day, because you're already familiar with it and invested in it, and because it's good to give back. There are all kinds of ways to contribute, such as writing code or documentation, hosting, creating artwork, releasing hardware specs, and donating equipment. When you're already a user and clued in to the community you'll probably have some ideas about what the project needs, or at least know who to ask. Contributing to an existing project is a great way to start building trust and social capital, which are the forces that fuel FOSS. (And pretty much everything, when you think about it.)
A great guide on managing an open source community is The Art of Community by Jono Bacon, the community manager for Canonical and its Ubuntu Linux distribution. (It's also available as a print and Kindle book.) Bacon manages one of the largest, most high-profile open source communities in Linux and open source, one that spans both the free-of-cost and commercial realms. His site and his book cover essentials such as developing a community management strategy, appropriate goals and objectives, governance, tracking progress and results, and managing conflict.
Among the things Bacon talks about is the importance of social capital, which is the gold coin of the open source world:
Community is fundamentally a social economy, and its participants build up social capital via their contributions. With social capital being, by its very nature, a product of social interaction, trust is critical. If people in a community don't trust you, you will be met with caution and you will struggle to build your social capital.
Be prepared to invest time and resources attracting contributors, and then keeping them. Merely uttering the magic phrase "open source" won't conjure up a pool of skilled developers happily toiling away for free. Potential contributors need to know that you will deal fairly with them, and not exploit them. The first question to ask yourself is "Why would anyone want to contribute to our project? What's in it for them?" Managing people is the most challenging part of any business, but even more so with a volunteer-driven project. Managing unpaid contributors is different from managing paid staff. They're immune to threats, won't take orders, and won't put up with typical corporate time-wasters like meetings and creating endless slideshows. So what is in it for them? They're motivated by rewards other than money: the work itself, being productive and building something cool and useful, being part of a larger community with the same goals, recognition, a sense of mission, a sense of excitement, learning new skills, taking on new challenges, giving back, a feeling of ownership, and more.
<digression>While people of all kinds take paying jobs because they need paychecks, for most of them money is not their primary motivator either. It might be worth taking a look inside your own shop to see what useless barriers are getting in the way of your good people.</digression>
Now you're ready to start your own project. We asked an expert on building and managing FOSS communities to share her expertise on creating a successful open source project. Stormy Peters is head of developer engagement at Mozilla, the former executive director of the GNOME Foundation, and the creator of the OpenLogic expert community.
Some shops like to keep a new project in house and not open it up until it has reached a mature state, but Peters says this is a mistake. "Run the idea by others while there is still time to make changes. Be open as early as possible. If you wait to open source your product until it's mature, then it's your project and it's done. If you want people to participate, own parts, and make meaningful contributions, you need to open up your project while there are still interesting decisions to be made. Make them feel like a part of the project.
"There is often a culture gap between business folks and the FOSS world. The best way to forge good working relationships between staffers and outside contributors is to have everyone meet each other and try out each others' worlds. Meet online, at conferences, at meetups. Your online staff should work together as you work with your outside contributors. So conversations should happen online, and decisions should be made in a way that includes outside contributors.
"One of the most important parts of community management is realizing how awesome your community is. Care about the people, and take time to thank them and congratulate them on their efforts."
As with the staff, so with the source code, Peters says the more inclusive, the better. "I think the source code should be made easily available to anyone. You may want to restrict those that can make changes to it to those who have established trust with you. Give commit privileges to people you trust. That trust can be built online over time as you work together on the project."
Peters cites many ways to turn users into contributors, including filing bug reports, writing documentation, creating artwork, coding patches, and moderating forums. "If you want your users to be contributors, you need to make sure your users know what opportunities there are. You also need to respond quickly and inclusively to people that express interest in helping."
Once you've gotten your community off the ground, you have to keep it flying high. All too often FOSS communities (like so much of the world) devolve to survival of the loudest and most insensitive. Your job is to look past the noisy ones and see which members are really contributing and doing good work, and to give them recognition and encouragement. Make a point of seeking out contributors from unlikely places. Women, students, non-white people, mid-life career changers, retired people, and people with disabilities can all be valued contributors; age, gender, health, and race have little to do with interest and ability. A lack of diversity leads to a lack of imagination, and this is fatal in the fast-moving tech world. A genuinely diverse community with people from all walks of life is a strong, nimble, creative community.
Part of bringing out the best in your contributors and encouraging new ones is having and enforcing a code of conduct. No one is so invaluable as to be immune from minding their manners. One toxic person will chase away many good contributors, and you'll never know how many. A Google search will turn up codes of conduct from other projects that you can use as models.
You may have to learn to let go of absolute control of your project, because micromanagement and strict controls won't work. Of course your project must have a focus and a direction, and good leadership keeping things on track. But you also have to leave room for experiments and tangents, because the great benefit of an open community is the variety and vigor of diverse ideas.
One big thing missing from most FOSS communities is an education path. Beginners are on their own until they develop useful skills, which they are expected to acquire on their own. Consider creating some sort of incubator for learners, a place where they can receive mentoring and critiques, at least in coding and documentation, which are two fundamental essentials. Take the long view – you don't know what demands you'll be facing in the future. Today's wide-eyed beginner could be just the talent you need tomorrow.
You may have to educate your management as well. They may have worries that open source code will "infect" their proprietary apps, and force them to be released under open source licenses. Some of the resources at the end of this article can help with this.
This may all sound daunting, like a lot of work. Which it is – there is no magic phrase, remember? But the benefit of an open community is more hands to do the work – not just developers, but contributors of many kinds doing a variety of jobs.
A good, well-run open source project can free your company to release better software faster, fix bugs faster, implement customer-pleasing improvements faster, and capture that all-important mindshare: generating buzz in your user base, and getting hobbyists and bloggers talking about the cool things your software can do. That sort of attention is priceless.
We've covered a lot of ground in a short article, so try these resources for more in-depth help:
Allowed tags: <a> link, <b> bold, <i> italics