Starting an open source project is easy: write some code, pick a compatible license, and push it up to GitHub. Extra points awarded if you came up with a clever logo and remembered to actually document what the project is supposed to do. But maintaining a large open source project and keeping its community happy while continuing to evolve and stay on the cutting edge is another story entirely.
Just ask the maintainers of Audacity. The GPLv2 licensed multi-platform audio editor has been providing a powerful and easy to use set of tools for amateurs and professionals alike since 1999, and is used daily by…well, it’s hard to say. Millions, tens of millions? Nobody really knows how many people are using this particular tool and on what platforms, so it’s not hard to see why a pull request was recently proposed which would bake analytics into the software in an effort to start answering some of these core questions.
Now, the sort of folks who believe that software should be free as in speech tend to be a prickly bunch. They hold privacy in high regard, and any talk of monitoring their activity is always going to be met with strong resistance. Sure enough, the comments for this particular pull request went south quickly. The accusations started flying, and it didn’t take long before the F-word started getting bandied around: fork. If Audacity was going to start snooping on its users, they argued, then it was time to take the source and spin it off into a new project free of such monitoring.
The situation may sound dire, but truth be told, it’s a common enough occurrence in the world of free and open source software (FOSS) development. You’d be hard pressed to find any large FOSS project that hasn’t been threatened with a fork or two when a subset of its users didn’t like the direction they felt things were moving in, and arguably, that’s exactly how the system is supposed to work. Under normal circumstances, you could just chalk this one up to Raymond’s Bazaar at work.
But this time, things were a bit more complicated. Proposing such large and sweeping changes with no warning showed a troubling lack of transparency, and some of the decisions on how to implement this new telemetry system were downright concerning. Combined with the fact that the pull request was made just days after it was announced that Audacity was to be brought under new management, there was plenty of reason to sound the alarm.
Meet the New Boss
It’s impossible to talk about the proposed changes to Audacity without acknowledging the project’s new owner, Muse Group. The organization is dedicated to developing and supporting audio tools and music software for content creators from all walks of life, and in addition to the Muse-branded packages such as MuseScore and MuseClass, they’re also responsible for Ultimate Guitar and Tonebridge. Despite the impressive catalog of software and communities that fall under their umbrella, representing hundreds of millions of users before Audacity is even factored into the equation, the Muse Group as an entity has only officially existed since April 26th (yes, that’s just eight days prior to the telemetry pull request).
Muse Group’s acquisition of Audacity was first acknowledged just four days later, in a YouTube video posted by Martin Keary (known online as Tantacrul) entitled “I’m now in charge of Audacity. Seriously“. On May 3rd, an official announcement was posted to the Audacity site confirming the news that they had joined the Muse Group and that Keary would take over as the new project leader.
The pace at which things were moving was alarming to say the least. But in his video, Keary made it clear that his intention wasn’t to strip the heart and soul out of Audacity. It would still remain free software under the GPLv2, and beyond some admittedly much needed user interface tweaks, would be the same program that millions of users had been enjoying for over 20 years.
Less than 24 hours after the official announcement of their acquisition had been posted to the Audacity site, the pull request to implement telemetry was opened.
Good Intentions, Terrible Optics
It should seem obvious that if you’re interested in a smooth transition of power and a happy community, the absolute last thing you should do is rush through massive changes that undermine a project’s core values within hours of taking ownership. Yet, that’s precisely what happened here. Not even a full day after users saw the first official word that the project had been absorbed by another group, unpopular changes were seemingly being rammed through the approval process without so much as a discussion period. For many, it was difficult to view this as anything but a hostile takeover of an established project by a group that didn’t even exist a week ago.
As you might expect, the reality isn’t nearly so racy. The Muse Group, looking to put development time and money into a revamp of Audacity’s antiquated UI and the squashing of some particularly tricky bugs, wanted the same insight into the software’s user base that they have with their existing projects. In fact Keary was instrumental in implementing a similar telemetry program for MuseScore back in 2019, specifically to determine which elements of the software were being used the most. With this data, the development team argued they could craft a more streamlined experience that better reflected the typical workflow.
The difference was, back then, it was announced with a well thought out and detailed blog post that articulated exactly what the development team was trying to achieve and how they hoped to do it. There were still some dissenting voices, but the explanation and clear goals helped to smooth things over. A similar post explaining the changes on the Audacity site could have helped avoid a lot of the confusion in those first few days, but unfortunately, somebody dropped the ball pretty badly this time around.
Eventually the pull request was amended with clarifying information, such as the fact that the telemetry would be opt-in and even then only applied to binary builds of Audacity released through GitHub and not distribution-specific packages. It even included a breakdown of what data would be collected, and how it would be used. The new information did quell some of the complaints, but others still took issue with the way the data was to be collected. For example, rather than handle it in-house, Muse Group was going to push all the telemetry through Google and Yandex. Collecting optional analytics for the sake of improving the Audacity user experience is one thing, but do we really need to funnel even more of our usage information through the search giants?
Message Received
When I started writing this, it really wasn’t clear how this situation was going to play out. Sure the community was mad, but as long as Muse Group kept to their word and made it so users had to opt-in before their data was collected, the reality is that most of them would cool off eventually. The chances of such a well established project actually getting forked over an optional feature that wasn’t even going to be included in distribution specific package repositories was slim to none. Would some users have jumped ship and found another audio editor for purely ideological reasons? Probably. But frankly, not enough of them to matter.
But before this article could go to print, the pull request in question was closed and Martin Keary himself dropped in to sort things out. He explained that the plan was to introduce the idea of telemetry to the Audacity community before actually proposing any changes, like they did with MuseScore, but that there was some internal miscommunication that caused things to happen out of order. Further, based on the response from the community, the decision was made to suspending any current plans to add telemetry to Audacity.
Looking ahead, Keary says the team is interested in getting community feedback on how they could implement some limited analytics for diagnostic purposes. They acknowledge that it needs to be handled in-house and not passed through a third party, but even still, there’s some debate about even adding tracking code to the project in the first place. Some members of the community have already suggested it be implemented as a plugin that’s maintained separately from the main Audacity source code, but it’s not immediately clear if that will be technically feasible.
At least for the time being, the Audacity community can rest easy. While there’s no question that Muse Group bungled things pretty badly here and got started on the wrong foot, it seems they’re looking to make it right and give the community the respect it deserves. We’ve often spoken of the incredible things that can be accomplished when a project embraces the creativity of its users and treats them as co-developers rather than as adversaries, and we’re hopeful Audacity’s new owners can harness that potential to guide the project through its second decade and beyond.
Recent Comments