blog-source/content/when_a_toy_isnt_a_toy_anymore.md

Title: When a toy isn't a toy anymore
Date: 2019-04-28T09:58-05:00
Author: Wxcafé
Slug: when_a_toy_isnt_a_toy_anymore

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?