2017-08-31 diaspora, opensource, software

I consider myself fairly experienced in regards to open source projects. Not only do I spend a lot of my free time on various projects, I am also in the very lucky situation to have a day job where I get paid for working on free and open source software. This put me into a position where I have seen quite a lot of projects, a lot of people, different working preferences, and, ultimately, a lot of different ways of managing projects.

In one of those projects, diaspora*, I gradually transitioned from an active code contributor position into something which can be described as the “project manager”¹, which was one of the main events that changed the way I look at open source projects these days, but I should probably clarify what I am talking about.

For people just getting started with open source, or people who do not spend a lot of time working on FOSS², these projects can be seen as something fun to do whenever there is free time; or as an opportunity to learn something new and to work with technologies one cannot fit into the day job. In general, participating in open source projects comes without any commitments, everybody can choose what they want to work on, and if they decide to not finish something, that’s cool. No obligation.

On the other hand, there are people who work on open source projects. I am a good example for that as well, since I work for Mozilla and get paid for working on Firefox, which is free and open source software. While I have a lot of freedom in my company, I would still get in trouble if I spend the majority of my time on something that is not on my team’s agenda or the company’s set of goals. Also, if I would stop working on a task halfway through, some people surely would get mad at me eventually.

These are the black and white ends of the scale, and obviously, there is a lot of grey in between. Core contributors to a large open source project surely feel responsible for the project in some way, and they commit themselves into finishing certain parts they deem important, so they are light gray’ish. Project managers of entirely community-driven projects are also on that scale, but for sure, they tend more toward the darker side of the scale, since they are the ones who are responsible that, while everyone is having fun, the software developed in that project is usable, and is heading in the right direction.

Sometimes, the two ends of that scale collide. Obviously, if you have a group of people who just want to have fun and a group who wants to ship a product, you have a conflict of interests that can vary in size. You cannot build an epic project with people who do not finish their work, but you also cannot have fun if you join a project where everything is strictly regulated by some management team.

In the last few weeks, I ran into a related issue multiple times while managing the diaspora* project, so I figured I need to clarify my opinion on that specific issue. And quite honestly, the large introduction you have just read is just there to make my point a bit more understandable.

The issue I am talking about is the following: our project has good documentation³ and help in regards to contributor engagement. We implemented and enforce a Code of Conduct to ensure everyone is acting and communicating in a sane and friendly manner. We wrote extensive documentation on how to get a development setup running, how to run tests, and how to submit pull requests. We have a nice, official, central, and easy-to-use tool (Discourse, that is) for project related discussions and decisions. We offer chatrooms for direct communication and created Discourse categories for people to ask questions. Questions about everything, really. We try to be there to help.

In my opinion, we are doing a pretty good job at providing information for new contributors.

Here comes the catch. Quite regularly, someone opens a thread on Discourse about a feature that has been discussed before. So we go ahead, link the old thread, and close the new one. We do this to avoid discussions that get torn apart by happening in multiple places. Sometimes people join IRC and ask how they can install their development environment. We go ahead and link them the documentation we carefully crafted, offering help if they are stuck in the process or have any questions. After all, the sole purpose of these documentation pieces is to enable new contributors to find the information they need, and it would be a waste (and unreliable, since people tend to forget things) if we’d repeated ourselves multiple times.

And then, sometimes, people complain. They do not complain about not understanding something, because that could be easily solved by asking questions via any channel we offer, and then having us improve the documentation. They complain about documentation being too large or discussion threads being too large or containing too much information.

This is the point where each contributor’s engagement is more important than contributor engagement in general. Nobody is forced to work on open source projects in their time; they want to work on the project. And that is cool. However, if you join a project and the project offers you a wide range of information on things you need to know to get started, it is your obligation to read those. Writing the docs takes a lot of time, and if a project spends the time to build these, contributors need to use them.

If a discussion about a feature is really long, or a documentation piece about setting something up is really extensive, there is a high chance it is that way for a reason. If you want to implement a feature and there is a long discussion, there probably are some tricky edge cases to take care of. If setup instructions are long and detailed, the setup is probably not the easiest thing.

When people are not willing to take advantage of the resources we provide, my basic response is usually a simple “Well, too bad, I am sorry”. You might receive different responses in cases where, for example, companies work on free and open source projects, and they decide to have people working on contributor mentoring (like Mozilla does, btw!), but please do not be surprised if you receive that kind of reaction when approaching projects. Most projects simply do not have the resources to take someone’s hands and walk them through everything.

You have a different opinion? Tell me about it, I would love to learn.