When we last checked in on the Audacity community, privacy-minded users of the free and open source audio editor were concerned over proposed plans to add telemetry reporting to the decades old open source audio editing software. More than 1,000 comments were left on the GitHub pull request that would have implemented this “phone home” capability, with many individuals arguing that the best course of action was to create a new fork of Audacity that removed any current or future tracking code that was implemented upstream.
For their part, the project’s new owners, Muse Group, argued that the ability for Audacity to report on the user’s software environment would allow them to track down some particularly tricky bugs. The tabulation of anonymous usage information, such as which audio filters are most commonly applied, would similarly be used to determine where development time and money would best be spent. New project leader Martin “Tantacrul” Keary personally stepped in to explain that the whole situation was simply a misunderstanding, and that Muse Group had no ill intent for the venerable program. They simply wanted to get a better idea of how the software was being used in the real-world, but after seeing how vocal the community was about the subject, the decision was made to hold off on any changes until a more broadly acceptable approach could be developed.
Our last post on the subject ended on a high note, as it seemed like the situation was on the mend. While there was still a segment of the Audacity userbase that was skeptical about remote analytics being added into a program that never needed it before, representatives from the Muse Group seemed to be listening to the feedback they were receiving. Keary assured users that plans to implement telemetry had been dropped, and that should they be reintroduced in the future, it would be done with the appropriate transparency.
It’s no secret that Internet Relay Chat (IRC) has lost some of its appeal in recent years. These days there’s plenty of free chat platforms boasting slick web interfaces and smartphone push notifications, to say nothing of social networks like Facebook and Twitter. The ability to communicate with like minded individuals from all over the planet in real-time is now something we take for granted, so it’s little surprise that newer and flashier protocols and services have steadily eroded the IRC user base.
But there’s often a hidden cost to using these more modern communication protocols. A lack of operational transparency naturally leads to concerns over monitoring and censorship, which makes such services a poor match for the free and open source community. As such, many open projects have eschewed these newer and more popular services for IRC networks that were developed and maintained by the community itself. Among these, the best-known and most respected is Freenode. Originally started as a Linux support channel in 1995, Freenode grew to become the defacto communication and support tool for free and open source projects of all shapes and sizes, and by 2013 had officially become the largest and most active IRC network in the world.
Unfortunately, the incredible legacy of Freenode is now being jeopardized by what former staff members are describing as nothing short of a hostile takeover. Through a complex series of events which actually started several years ago, control of Freenode has been taken from the community and put into the hands of an enigmatic and wealthy entrepreneur who claims his ultimate goal is to revolutionize IRC and return it to the forefront of online communication. Here’s where it gets weird.
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.
Free and open-source software (FOSS) doesn’t have to be entirely separate from the concept of bringing in money, but the path to monetizing is maybe less clear than it could be. To help address this, [Drew DeVault] has shared some concise thoughts on different ways to monetize FOSS work and projects. [Drew] observes that monetizing one’s own projects is one approach, but that it is entirely possible, and less difficult, to make money by participating in open source work in a more general sense.
There are companies and organizations out there who may make their money otherwise, but are nevertheless involved in or reliant upon open source software for running their business. Such companies are a good starting point for anyone looking to work in FOSS, and [Drew] shares a clever tip for finding them: use git to clone the software repositories of large projects that are of interest to you, then run this command:
This will extract the domain names from the last 100,000 commits to the repository in question; a good set of leads to companies and organizations that are invested enough in FOSS to contribute, and who may be willing to pay for such work.
There is also the option of monetizing one’s own projects, which [Drew] says is the more difficult approach. He shares tips on monetization options, but cautions that fundamentally one is building a business when going this route. One should therefore be prepared to face the attendant non-software-related problems in the process.
Linux users are more likely than most to be familiar with Chromium, Google’s the free and open source web project that serves as the basis for their wildly popular Chrome. Since the project’s inception over a decade ago, users have been able to compile the BSD licensed code into a browser that’s almost the same as the closed-source Chrome. As such, most distributions offer their own package for the browser and some even include it in the base install. Unfortunately, that may be changing soon.
A post made earlier this month to the official Chromium Blog explained that an audit had determined “third-party Chromium based browsers” were using APIs that were intended only for Google’s internal use. In response, any browser attempting to access features such as Chrome Sync with an unofficial API key would be prevented from doing so after March 15th.
To the average Chromium user, this doesn’t sound like much of a problem. In fact, you might even assume it doesn’t apply to you. The language used in the post makes it sound like Google is referring to browsers which are spun off of the Chromium codebase, and at least in part, they are. But the search giant is also using this opportunity to codify their belief that the only official Chromium builds are the ones that they provide themselves. With that simple change, anyone using a distribution-specific build of Chromium just became persona non grata.
If you’re looking to rid your day to day life of dead trees, there’s a good chance you’ve already heard of the reMarkable tablet. The sleek device aims to replace the traditional notebook. To that end, remarkable was designed to mimic the feeling of writing on actual paper as closely as possible. But like so many modern gadgets, it’s unfortunately encumbered by proprietary code with a dash of vendor lock-in. Or at least, it was.
[Davis Remmel] has been hard at work porting Parabola, a completely free and open source GNU/Linux distribution, to the reMarkable. Developers will appreciate the opportunity to audit and modify the OS, but even from an end-user perspective, Parabola greatly opens up what you can do on the device. Before you were limited to a tablet UI and a select number of applications, but with this replacement OS installed, you’ll have a full-blown Linux desktop to play with.
You still won’t be watching videos or gaming on the reMarkable (though technically, you would be able to), but you could certainly use it to read and edit documents the original OS didn’t support. You could even use it for light software development. Since USB serial adapters are supported, microcontroller work isn’t out of the question either. All while reaping the considerable benefits of electronic paper.
The only downside is that the WiFi hardware is not currently supported as it requires proprietary firmware to operate. No word on whether or not [Davis] is willing to make some concession there for users who aren’t quite so strict about their software freedoms.
On the whole, hackers aren’t overly fond of other people telling them what they can and cannot do with the hardware or software they’ve purchased. Unfortunately, it’s becoming more and more difficult to avoid DRM and other Draconian rules and limitations as time goes on. Digital “eBooks” and the devices that are used to view them are often the subject of such scrutiny, which is why [Joey Castillo] has made it his mission to develop a open hardware eReader that truly belongs to the user.
[Joey] has been working on what he calls the “The Open Book Project” for a few months now, and he’s just recently announced that the first reader has been successfully assembled and powered up. As is usually the case, a few hardware issues were identified with this initial prototype. But it sounds like the device was largely functional, and only a few relatively minor tweaks to the board layout and components should be necessary before the hardware is ready for the masses.
If you’re feeling a bit of déjà vu seeing this, don’t worry. The Open Book Project has taken a somewhat circuitous path to get to this first prototype, and [Joey] had previously developed and built the “eBook Feather Wing”. While they look very similar, that earlier incarnation required an Adafruit Feather to operate and was used to help refine the firmware and design concepts that would go into the final hardware.
The Open Book is powered by a ATSAMD51N19A processor with a GD25Q16 2MB flash chip to hold the CircuitPython code, and a microSD slot to store the actual book files. It also features support for audio output via a standard 3.5 mm headset jack, an RGB status LED, and expansion ports that tap into the I2C interface for adding whatever other hardware you can dream up.
One of the most interesting aspects of this Creative Commons licensed reader is the extensive self documentation [Joey] has included on the silkscreen. Every major component on the back of the PCB has a small description of its purpose and in some cases even a breakdown of the pin assignments. The idea being that it not only makes the device easier to assemble and debug, but that it can also explain to the curious user what everything on the board does and why it’s necessary. It’s a concept that makes perfect sense given the goals of the Open Book Project, and something that we frankly would love to see more of.
[Marc Juul] presented his work on a FOSS operating system for older-model Kindles at HOPE XII as a way to avoid Orwellian monitoring of the user’s reading habits, so it’s interesting to see somebody take this idea to the next level with completely libre reader hardware. Unfortunately none of this addresses the limited availability of DRM-free eBooks, but one step at a time.