I was on a call with a friend from a large corporation this morning discussing building a new open source community for some shared software. We didn’t talk about the legality, but what was required to successfully start it up. He mentioned that they had some tactical things planned but wanted my input on what else he hadn’t thought of. Needless to say, I had my opinions.

Over the last 4 years being in the Open Source Community at Chef I’ve helped cultivate community groups in different portions of our industry, ranging from committee driven OpenStack to corporate VMware, and seen different things succeed and fail. Here are a couple takeaways I’ve learned and hopefully might help someone later on.

Starting an Open Source community isn’t just a Github repo and a wiki.

It’s amazing how thinking about Open Source in the modern day still people think you put a repository up on Github and the Open Source horde will come to help you out. That’s not the case, it requires so much more most never see. You need to market your code, you need to get people involved, you need to have folks already engaged and committed to shepherd them through the process of engaging with what you have created. This also doesn’t happen overnight, this takes months or years even of dead silence or a trickle of engagement then if you’re lucky might create a community. The scary thing is that because it’s all volunteers that help you, you have to continue to cultivate it, and if you or your project does something wrong you can lose all of your members overnight. Yes, it can take months or years to build it, and overnight people’s priorities can change and you can be left alone. It doesn’t sound all unicorn and rainbows, mainly because it isn’t; it’s hard and unforgiving.

Building and leading an Open Source community is like organizing a trash pick up in your neighborhood. No one cares about the permissions you had to negotiate to get the local board to say yes, they are there to help you beautify the area. It’s still good to feed them or celebrate the best workers, but in general, they don’t care about the back end at all.

I was trying to think of a way to describe a response I made about the amount of “political” work required and came up with the above quote. He asked me about “When you said political, is that the community or the corporate political work that I have to do.” I looked out my window and saw a soccer field that is maintained by my local MUD and thought about how much it would take to get a trash pickup to get done. Then it dawned on me, that’s a perfect bite size description of leading an Open Source community.

I didn’t know how to explain to someone that is just starting this journey that the Open Source Community members don’t generally care about the hardships that an Open Source leader goes through on the day in day out. It felt very negative and would cause some friction, but honesty is always the best policy. The sooner this person realizes that the people involved are there as volunteers working for free on a shared project wanting to learn, help, and socialize not have to worry about the struggle and the logistics and maintenance of the project.

Let us pull apart the statement and discuss each portion in a little detail.

Building and leading an Open Source community is like organizing a trash pick up in your neighborhood.

If you’ve ever done volunteer work, this should hit home. You know the amount of work that is involved getting just a simple trash pickup together. It’s not just putting up a flyer or Facebook Neighborhood post saying “Saturday morning, 9 am Trash pickup.” Oh no, it’s more than that. You need to get resources together for it, you need trash bags, ways to pick up trash, water, safety gear, ways to transport the trash away from the collection points, set collection points, people to help staff these points and give out resources; this is what’s just off the top of my head, I bet there is much much more to be done tactically. This is just the thought of “Saturday morning, 9 am Trash pickup.”

No one cares about the permissions you had to do to get the local board to say yes, they are there to help you beautify the area. It’s still good to feed them or celebrate the best workers, but in general, they don’t care about the back end at all.

Now you’ve figured out the tactics to get this done, now let’s think about the next step. You need permission from your local MUD/board/HOA to get this done. This is a great analogy to the work as an Open Source leader you might have to do on the back end for the rights of a company. If you deal at all with intellectual property laws or have specific licensing agreements the work you have to do to deal with those choppy waters no one will care or help you with. They are there to help the project, being Open Source means they can help and isn’t their responsibility to make the corporate overlords happy. That’s your job, you are the focal point the person that has to figure out the correct process. You quickly learn to have a thick skin, you’ll get shot down and frustrated, and assuming you’re building and leading an Open Source community for a corporation, this will be the largest and most frustrating part of your job.

Finally, one of the best portions of the job is the ability to celebrate the members of the community. The ability to say thank you and highlight the committers to your project to build something together is the reward. It’s amazing what the human engineering spirit can do when there is a common goal and resources to make it happen. Most, I would say at least 80% of Open Source projects never get to this point, but if you do is something to be celebrated. You can have all the corporate backing to make this happen, but if you don’t grow the community organically you’ll never see the return on the investment.