Let’s say, for the sake of argument, that there’s this guy named Nick.
Nick is a nice person. He’s friends with a lot of queer people. Maybe he doesn’t always get everything about Socialism or Communism but he agrees that the world is unfair, and that a better distribution of resources would be way better. He’s European, so he sees that the US “right wing” is a bunch of fascists, and he doesn’t hesitate to say it. All in all, a pretty good guy.
Nick is also a developer. He believes that Free Software in and of itself is a Good Thing for the world, and that you should use it if you can, but he also sees that of course usability is important and that users can’t be blamed for going with a proprietary solution if the FOSS one is too ugly or unusable.
Nick is getting weary, because the company that edits one piece of proprietary software he uses (because he has to use it) doesn’t seem to want to do anything except make its own product worse, and more hostile to its own users. “No problem!”, thinks Nick, “I’ll make my own!”. And he’s a dev! So he can.
And so he does! For months, he takes of his own free time and works on this concurrent product. And it gets better and better! He fixes all the problems he sees in the product, and he shows it to his friends. And his friends get excited about it too! So he decides to release what he has, which is already pretty good, making sure everyone knows it’s only a beta release.
A few weeks go by. A lot of Nick’s friends have started using his software, which is great! They’re reporting bugs and stuff, which help him make it better! But they’ve also told all their friends, which is a little less great, because these people don’t necessarily know it’s a beta release. But Nick keeps at it, and improves his software, again and again. More and more people are hearing about it, by word of mouth, and it’s getting better and better.
And Nick is happy! Cause let’s be honest, we all like it when people use our things. It’s only natural, we like when things we make are successful, and especially when it helps others get out of a bad situation. But at the same time, Nick is a bit frustrated, cause he’d like everyone who uses the company’s product to switch to his. Cause his is so much better! If only they knew! And that, too, is only natural. We don’t like seeing people struggle when they shouldn’t have to, and it’s especially frustrating when you’re the one trying to provide a solution.
But Nick overcomes this frustration for now, and decides to keep building his product for the people who are using it. And he’s got some work to do! His users, most of whom are queer people (remember, he has a lot of queer friends… So when they told their friends, well…), have plenty of suggestions. Turns out the company’s product has actually never satisfied them, and they actually really hated it but used it nonetheless cause, well… there was no alternative. But now that there is, there’s no reason to only make it as good (or as bad) as the original was! Let’s improve it! And so they suggest lots of stuff. And some of them are developers too, so they submit PRs and patches. Pretty soon, entire features aren’t developed by Nick anymore.
Nick is very happy about this at first (obviously), because… well, it cuts his development time, new features get added (most of which he wanted to add in the first place), and some very good ideas that he wouldn’t have though of are suggested. But more importantly, he’s really happy that others care about his personal project. And of course he does. That’s only natural, when we build things and others care about them enough to build them with us it makes us feel loved and recognized!
But then, he starts to be less and less enthusiastic about these other contributors. Yes, they’re great people and all, but… some of the stuff they suggest is really not how he envisioned his project. They make good points about it, too, which is really problematic for him because they’ve been really helpful, and he doesn’t want to hurt them… And they’re also the fact that they’re arguing that some of the features they’re suggesting are specifically about them being queer, and he doesn’t want to seem like he doesn’t care about queer people. But he starts to kinda feel like his project is being taken out of his hands.
Time passes, and features are added to the software. Some are Nick’s ideas, some are other people’s ideas that Nick like… and some he doesn’t feel great about but hey, it’s helping other people, right? So he adds them anyway. But today, a PR was opened by a contributor, someone who’s been very active in developing the software, and Nick really, really doesn’t like it. He hates it so much, he’s at the brink of answering that he won’t merge it. He doesn’t have any rational reason for it, he just… doesn’t like it.
But then he has an idea. What if, instead of telling the contributor he won’t merge the feature, he just ignores the PR. The contributors have write access to the repository, but they always wait for an ok from Nick before merging stuff. If he acts like he hasn’t seen the PR, and ignores it, it will slowly start to develop merge conflicts until the contributor has to rewrite it entirely… And then he can still ignore it, eternally. The upshot being that he doesn’t have to start conflict with the contributor, something he really, really doesn’t want to do.
So he ignores the feature. And he was right! It does develop merge conflict. The contributor nags him once or twice about it, but then kinda forgets about it, so everything is good. But after a few weeks, another PR he doesn’t like is opened by someone else. Well, he can just ignore it too, right? Yes, he can… Until at some point, the first contributor remembers about their PR… And they ask him, if he doesn’t have the time to review the PR, if the other contributor could do it. Ah, now that’s problematic… He can’t say yes, because the two contributors would probably agree and merge that feature he really doesn’t like. But he can’t say no either, because that would be weird and imply he doesn’t trust other contributors.
So he tells them he’ll review the PR, and a few minutes later finally comments that he doesn’t want to merge the feature. It’s great and all, but he doesn’t like it. “But it helps me use the software, it’s a pain to use otherwise…”, says the contributor. “Yes, but I don’t like it”, replies Nick. “Well, it’s an accessibility issue”, says the contributor, “and queer people like me need this kind of features to use the software”. Nick still doesn’t have any rational argument, so all he finds is “well, it’s my project, isn’t it? And I don’t want the feature, so I am not going to merge it”. And with that, he closes the PR. Of course he feels bad, and he feels even worse when the contributor comes to see him to talk about it in private and ask him what they can change about it to make him like it better. “Nothing”, he says, “I really just don’t like the idea”. And after a while, the contributor, who seems a bit upset, says that they’re not really happy about that but it’s okay, whatever.
A few months go by, with a few other closed PRs, pretty much in the same way. Then the company does another change to their software, and a lot of their users really don’t like it. And instead of just acting upset a few days but sticking with the company’s software like they’ve always done, this time a few of them (the most technical of them) decide to move to Nick’s software, since it seems better now.
Nick’s really glad about that, he’s wanted to attract power users of the company’s product since he started building his own! The queer people are great, but they only represent a fraction of the company’s software users, and they have their own usage habits (as he’s seen from the PRs…). And, once again, that’s understandable, because we all like things we build to be used and liked by lots of people! And so the new users pour in, soon overnumbering the existing userbase. And they’re a bit surprised about the specific features that have been added to the software they’re used to, but they soon get used to it and start to really like them. They also like the fact that the community is smaller, and tighter-knit, than the one of the company’s software. So most of them are happy, and keep using his software, and Nick’s feeling pretty popular.
And that keeps on for a few months, with irregular influxes of new users, and still a few PRs he doesn’t like, but now the new power users have started to suggest new features too, features that Nick didn’t bother implementing when building his software but that they liked on the company’s product. And Nick doesn’t feel either way about these features, but he thinks that if he implements them other, less adventurous users of the company’s software might migrate over. So he starts working on those, until one of the people from the first cohort of contributors comes and tells him that that feature he’s starting to implement actually really impairs their ability to use the software. And Nick doesn’t really understand that, he doesn’t get how adding that feature could cause them problems. So he keeps working on it and merges it into the codebase, which (understandably) upsets the first contributor quite a lot. Nick feels kinda bad about it, but after a bit a lot more new users start arriving, and he moves on because he’s so excited about all these new uers.
After a few more weeks, one of the first cohort’s contributors opens a PR, but merges it in with another contributor’s approval instead of asking Nick. Of course, Nick is upset about this! It’s his project, it’s really nice of them to contribute to it but they should still ask him before merging stuff. So he makes an angry comment, and leaves it at that.
A few days later, this happens again. They tell him that he’s been working a lot on the newer cohort’s features, and while that’s okay and he can do what he wants with his project, there’s still a lot of open issues and work to do, and since he has left PRs to die in the past they wanted to merge these before they develop conflicts. He locks down merge access to only him, and tells them that they’re right. It is still his project, and he’ll be the one deciding what to merge. Then he goes back to work on those features ported from the company’s software.
Contributors from the earlier cohort are slowly leaving the project, one after the other. Some of them, who contributed a lot of important features, band together and make a fork. Nick doesn’t like how they present it as a better, community-driven version of his project. His also is community-driven, isn’t it? Lots of people suggest features and open issues, and he accepts a lot of PRs! The fork ultimately isn’t really successful anyway, few people use it and they keep rebasing on his code every few weeks because they don’t want to miss out on his software’s features. Nick ignores them.
Hey, some journalist contacted Nick to do an interview with him, about his project! He’s been getting invitations to open-source software conferences, too, to give talks about taking on the company. That makes him really excited, and nervous too, but he’s really satisfied to finally get recognition for all the hard work he’s done. He talks with the journalist, and tells them how hard it’s been, and how he’s very happy to have implemented all those accessibility features that the company wouldn’t add to their software; and how he’s happy that company power-users are liking his project. He goes on and on about how the company is hurting their own users, and the only ones that matter. He goes away from that interview pretty happy with himself, and sure that this will bring more users to try his software.
After the article is published, the old cohort of contributors isn’t really happy. They’re not happy about how he called the power users “the only users that matter”, and they’re especially not happy about how he said he was proud to have implemented the accessiblity features when they did most of the work, they submitted the ideas for the things they didn’t code themselves, and he still won’t merge some of the accessibility features they made. He tries to explain how the interviewer asked about the features and didn’t understand the concept of collaborative work on software, and how they thought he made the whole thing, but the contributors call him a lying hypocrite and leave it at that, and they don’t wanna hear from him again. He’s kinda hurt by that, but he still feels he didn’t do anything wrong, so…
Life continues like this. He keeps ignoring the (rarer and rarer) PRs that he doesn’t like, because he doesn’t like confrontation. He keeps implementing features that he thinks the company software’s users will like, to draw more and more of their users towards his project. He’s getting paid through donations for his work, so he quits his job and works on the project full time. After a while, he hires a Project Manager, to try and manage everyone’s expectations and keep everyone happy. But they start telling him what he should and shouldn’t merge (the nerve! He hired them to manage the contributors, not him!), so he doesn’t renew their contract. The project becomes larger and larger, the userbase grows steadily. Sometimes old contributors come back to fight on a particular issue or two, but they never stay long. He doesn’t get why, after all he’s not confrontational at all!
Anyway. The project will continue, and the users will keep using it. But it doesn’t feel as fun as it did for Nick… Nor does it for the contributors.
Of course, this whole story is fictional, and any resemblance between it and events or persons in real life is pure coincidence. In this blog post I wanted to talk about Open-Source development, and how maintainers too often don’t see that they have the responsibility of the community that uses their software.
I know the argument over “devs should be free to do whatever they want with their own work!” vs “devs have a social responsibility to (at least) fix bugs in the software they open-source and that people use” is a pretty old one, and both sides have obvious points that are worth taking into account. My argument here is that when either your project becomes too large, or your community is composed of marginalized people, you do have a responsibility towards them, and if you don’t want to assume it yourself responsibly you should either give the governance of the project to someone else (and fork, if you’re not happy with the direction the project takes without you) or direct contributors to a fork that is community-driven.
Death of the author and all that, you know? People will do with your creation whatever they want to, and if you’re not ready for them to do that, you shouldn’t release it to the world.
When your toy becomes used by so many people… well, maybe it isn’t your toy anymore.
That’s my opinion, anyway. But I’m not a dev, so what is my opinion even worth?