Our relationship to code: How much power do companies have over open source?
The MUSE group wrote a telemetry proposal as a pull request, and it backfired. Linux users are usually safe from telemetry thanks to distro maintainers, so why are people still mad? And what does that say about the way software is distributed as a whole?
People were angry because MUSE wanted to introduce telemetry, it’s as simple as that!
Is it though?
First things first, I would like to make it clear that I do not condone the actions of MUSE group in any way. All I want here is to use that situation as a case study.
1. The telemetry proposal
Here’s a quick run-down of what I understood from the discussion around the telemetry PR of May 4th
- A MUSE developer submitted the pull request, containing working telemetry code intended for Audacity, to the Audacity repository.
- The community found out about the pull request, which promptly caused a backlash.
- The most obvious change to Audacity’s governance to people was the involvment of Tantacrul, so the community lashed out to him.
- Tantacrul explained, in an official response on behalf of MUSE, that the intent was for the PR to serve as a proposal to the community.
Now that I wrote these words out, two possible lines of thought come to mind:
A: MUSE had intended for people to find out about the PR through their official forum post, as they did with MuseScore.
Maybe. Or at least, that’s what they officially said. I guess pull requests aren’t a very subtle way of expression, but given that their alternative would have been to work on a private fork then come out of the blue with an instantly implemented telemetry PR, I’d say it still was for the better.
Of course, the community wishes that they talked about the idea before starting work on it, but on the other hand, they may have thought that simply asking “Hey, mind if we add telemetry?" would have caused most people to refuse anyway, and that an implementation would have been more clear.
B: MUSE had intended to implement telemetry as fast as possible. The PR was too complete to just be a proposal.
Except, something just doesn’t fit. In fact, looking at the commit dates, the whole “work on a private fork then come out of the blue with an instantly implemented telemetry PR” is precisely what they did. And of course, the community lashed out on them. As far as was disclosed, there was seemingly no reason to release their work ahead of the forum post they had intended to make, unless they wanted to merge the changes as fast as possible.
The truth is probably somewhere in between, but comparatively speaking, the public reaction was a lot more tame than for what happened next.
Again, MUSE reminded people that the new data collection code can be disabled through a compile-time option.
Compile-time options are expected to be manipulated by users, but come with the implied requirement that said user should be sufficiently proficient in computing to know how to compile their own programs in the first place. As such, it is fair to say that, regardless of intent, these options will impact the uninformed and damage the image of an app as a unified product whose behavior is identical everywhere.
Moral of the story
It is much too early for me to give a definitive opinion on the situation, but as a community, we should consider our choices in software distribution, and how they can affect our users in the long run.
Just like with installers, the ability to customize and control the build process is an important part of a sane relationship with software. When the defaults are changed, it’s as if the very philosophy of the app is being taken away from the community, who then feel powerless. Such is the irony of modern open-source.
And to MUSE: Not every user of Audacity is a developer, and we are acutely aware of that, which explains the community’s overprotective stance. Code is law, and proposals should first be formulated in words, before being written down to code.