The responsibilities of an open-source developer

The proudest moment anybody initiating an open-source project can experience is when that project finally gains the momentum to make a difference within the community it targets. When my colleague Martin and I published the first release of Fluent Assertions on CodePlex in 2011 (yeah, those were the days), not even in our wildest dreams we expected that by 2016 our NuGet package would have been downloaded that much. Next to that, almost every week, somebody posts a blog post about our little .NET assertion library. And if you scan nugetmusthaves.com, you'll find 54 packages relying on Fluent Assertions. It supports all current .NET versions and platforms including Xamarin (by Oren Novotny). And even the .NET Core Lab team is using it, which is why we support CoreCLR, .NET Native and .NET 4.6 since it earliest betas.

But with that popularity comes great responsibility…

Rather than working on the next killer feature or API, you'll be spending a lot of your private time answering questions on GitHub, Gitter, StackOverflow or email. And if you do that, stay friendly and constructive. Thank them for taken the time to file an issue, and do that in a timely fashion. Nothing is more annoying for somebody that uses your library, runs into an issue he or she can't resolve, takes the time to post about it and doesn't get a response in weeks. That sure is a recipe for losing some fans quickly. Even if you believe they've made the mistake and everything is fine with your library, take the time to explain your reasoning behind it. More than often I expected to get some nasty repute when I rejected an issue. But I've come to learn that people are just happy to get some help to get them going.

Sometimes the issue is more complex, e.g. when somebody is using your library in an unsupported way (you'll be surprised what people think of sometimes). Explain them the design philosophy behind your library and why you're rejecting a particular issue. If possible and - like Fluent Assertions - you offer extension points, provide them with a link to some example that shows them how to build their own extensions. If it's a potential bug which you can't reproduce easily, be not afraid to ask them to help you reproduce it or request a little project that reproduces the problem. Now, most open-source developers I do know don't have the free time to build every possible feature that is requested. So if you do think their issue or suggestion has merits, tell them that you're accepting pull requests.

Now that I mentioned that, I need to explain my philosophy on using open-source software in professional software development. If it's up to me, you can use whatever open-source library you want to use, but only if it meets one of following two requirements.

1. It's backed by a large group of developers or contribution base. So if one of the original authors abandons the project, there's no risk to the project itself.
2. Its code is well-written, readable, properly documented and heavily covered by unit tests at a level that your confident enough to continue supporting the code as part of your own code base.

With this in mind, I think I have the following responsibilities towards my own project.

• Ensure that all code uses the same layout, coding styles and naming conventions.
• Make the code a testimony on how I envision high-quality code.
• All public and protected APIs are properly documented.
• All changes are backwards compatibility with prior versions. If breaking changes are needed, they get staged for a next major release.
• The API is consistent and follows the Principle of Least Surprise.
• All edge cases are covered by well-factored unit tests.
• Ensure a clean source control history that will make it easy for contributors and users to find out what has been fixed when.

These will hopefully encourage more people to join the project and will lower the threshold for those cases where somebody needs to fork the code and start to maintain it themselves.

I expect it to be no surprise that these responsibilities in some form transfer to contributors who submit a pull request. And that's the hard part. You should show contributors the respect that they deserve. They've decided to commit a potentially substantial amount of their free time to provide you with a pull request that solves a particular bug or adds a feature, so show how much you value that. Sometimes you won't get a single PR in weeks, but then you suddenly receive a couple of them in a short time. If you're lucky, those PRs meet whatever requirements you've set (e.g. by using Github templates) to honor responsibilities such as I mentioned above. If not, you have to decide how to deal with that. You can decide to take the PR as-is and do the rework yourself, or, as I tend to do, do a thorough code-review and ask them if they're willing to pick up the rework. And that's a double-edged sword. Either you do the work in your precious free time, or you risk discouraging contributors from contributing again.

So what do you think about this? Do you agree with the responsibilities of an open-source project? Would you accept any PR or do you prefer to uphold you standards? I'd love to hear your thoughts by commenting below.

That being said. Now you know how I think about all this, if you would like to join the ranks of those that made Fluent Assertions such a great library, we have lots of work up for grabs. Oh, and follow me at @ddoomen to get regular updates on my everlasting quest for better solutions.