Do FOSS Projects Need An End User TOS Too?

There’s been a lot of discussion lately about the need for FOSS (Free Open Source Software) projects to have a CoC (Code of Conduct).

A recent tweet I saw made me think about something CoCs are missing and inspired me to write this post.

First we need to step back and look at what a Code of Conduct is and why there has been such a recent clamor for projects to adopt one.

At it’s very basic core, a Code of Conduct is a document that lists a set of rules and responsibilities of an organization. This normally includes items about the expected behaviors of the members of the project.

This sounds like a good thing and I would expect everyone would be for including a CoC in a project. Who wouldn’t want a nice defined document that helps promote a good healthy working environment?

Due to a few recent nasty incidents in some projects there has been a push to get many large projects to adopt CoCs to prevent future incidents from occurring.

That’s all fine and good but something we are missing is defining the expectations of the end users of the code these projects create.

FOSS (Free Open Source Software) projects are created and run in a majority of cases by volunteers. These are dedicated and hard working software developers that give up their limited free time to create awesome software for no pay.

They could be working on projects that earn them money, they could be hiking a trail, watching a movie, reading a book, or even just taking a nap. They could be doing so many different things but instead they use their time to write code.

It takes a certain type of person to want to work on FOSS projects. A developer could spend months or years working on a project but get little if no respect for it. Then it gains traction and many people start using the app and spread the word about this great app. Congratulations are at hand for the devs! They have a successful project!

That’s when often the dark side of end users appear. They found this great app or code library that is useful to them. Well except for that one missing feature or a bug that has cropped up. So they reach out and request that the developers add that one feature that would be useful for them or notify them of the bug.

It’s probably not that bad at first and the devs are able to quickly get the bugs squashed and throw in a couple new features here and there and put out a new release. Soon however that’s not good enough. More and more demands come in and you have to start prioritizing them. After all this is just a hobby not your day job. Sure it would be nice to get to all these features, and you know you should get some of those bugs fixed, but you do have a life outside this project.

Users don’t care about that. They start becoming nasty and complaining that the code is buggy crap and the developers are lazy. What was once a fun hobby has become a rather evil demanding monster. It’s become a full time job but one that doesn’t even pay!

Maybe it’s time for projects to add an End User ToS (Terms of Service) as well. A document that clearly defines to end users what the project is, a free app that is created by dedicated volunteers. A document that spells out what the expectations are for the developers, to dedicate a healthy amount of free time that balances the needs of the project with the needs of the developer. A document that the spells out the expectations of the end users, to remember that the project is one managed by unpaid volunteers that have a life that does not revolve around attending to every whim of the user that didn’t even pay for the software they are using.

It sure seems like we need something that reminds users that bad behavior directed at developers will not be tolerated and that they are expected to show respect and understanding for those hard working individuals that without them the project wouldn’t even exist!

What do you think? Is this something projects should include?

Avatar
Alan P. Barber
Software Developer, Computer Scientist, Scrum Master, & Crohn’s Disease Fighter

I specialize in Software Development with a focus on Architecture and Design.

comments powered by Disqus
Next
Previous