[July '21]

June makes FOSS and takes our Twitter mic from July 21 to 28. Thank you, June!

Please tell us about yourself

I’m a crazy embedded software engineer that loves to hack on low level hardware, and in my spare time, I love to teach others how to do the same via my YouTube channel, Nybbles and Bytes, as well as contribute to a number of FOSS projects I either run or contribute to.

What are you working on right now?

My current big FOSS project is a physical hardware simulator for the Commodore 128 that runs the VICE emulator, called the V128. In my spare, spare time, I also took the existing open source Logitech G13 gameboard driver (g13d) and rewrote it totally with a fancy GUI to make configuring the thing easier. The source for both are on GitHub, here and here, respectively.

What is most interesting about that?

The idea behind the v128 project is to make something akin to the C64 Mini, but focused simulating the physical interactions as well as the software interactions. This includes things like floppy disk swapping, hardware support for real joysticks, etc. It also includes a bunch of interesting hardware and software challenges: we need to integrate support for various real peripherals into the VICE emulator, without diverging too much from upstream source. By far the biggest challenge right now is integrating NFC chip reading into the operating system and emulator so that we can physically swap floppies instead of relying on a bunch of menus and files on disk.

The G13 Configurator, on the other hand, includes a unique extensibility mechanism via DBUS that allows for applets to be written and displayed on the G13’s built-in LCD display, and was by far the hardest thing I’ve written for it so far.

How did you first discover FOSS?

I think it was waaay back in 1995 when Slackware was king, and Linux had just come on the scene seriously with the 2.0 series of kernels. Besides goofing off with Linux, I had been introduced by a friend in college to the great DJ Delorie’s DJGPP tooling to write games for DOS, and that system included source code. At the time, having the source to the tooling was hugely empowering, as prior to that I had been locked into using proprietary systems with inscrutable documentation, and all sorts of bugs. DJGPP taught me what the power of open source really could be at the time – any time I found a bug or a problem with the tooling, I could find and fix it myself, without having to wait for a fix from some faceless corporation. It was a liberating and powerful concept at the time, because computers weren’t anywhere near as connected and “on-line” as they are today, and shipping bits between them was an arduous task. Updates for proprietary software took years, and bugs in tooling was the bane of the programmer’s existence.

What prompted you to start contributing to FOSS?

It was a sort of natural progression, I guess. With source code being readily available, it was easy to just dig in and fix things, so I was regularly doing it for my own personal needs. I never thought about distributing the patches at the time, but with places like SourceForge appearing, and tools like Subversion and Git coming on the scene, it only seemed natural that I should open up my contributions to the world.

During the early days of GNOME 2, the sound dialog was missing a “remove” button, and I wanted one because the oversight annoyed me, and it was a super easy fix. So I wrote a patch and emailed it, and whaddya know? It was merged in! It wasn’t until around the early 2000s that I started seriously making bigger projects, though, but recently I joined the VICE team and started contributing bugfixes and feature changes to the emulator to support my needs in the v128 project as well.

Why should others get involved with FOSS?

The more the merrier: the more folks involved, the more we can accomplish as a community or team. FOSS is often worked on in spare time, so there’s lots of little things and even big things that need help being planned out, fixed, or even discovered. Between translation of strings, bugfixes, feature development, feature planning, refactoring, documentation, and testing, there’s room for everyone to contribute in what ways they can. Even releasing small individual “itch scratching” projects, like my Logitech G13 Configurator application is useful, since anyone with the same itch can help to improve the result of your own hard work. More folks contributing means you as a team can do bigger and crazier things. I mean, just take a look at the Gnome, KDE, and Linux kernel guys: that stuff is seriously hard work, but because they have so many people involved, it’s actually possible.

How should they get started?

If you’re a developer, start small – find something that annoys you, or that seems to annoy the team somewhat. Talk. Email. IRC. Or whatever else the team uses to communicate. Figure out what needs fixing or tweaking or doing, and go do it. Learn the tooling, the code style, and ask for review during the first few tries to ensure you hit all the notes. As you build up trust with the team, you can take on bigger and crazier things. If you’re feeling leader-like, make your own projects source available publicly, either via GitLab, CodeBerg.org, or other public hosting systems.

If you’re not a developer, you can still contribute: there’s documentation that needs writing, websites that need maintaining, bugs that need to be found (there is never enough QA and testing!).

What difficulties and limitations do you see with FOSS?

There’s a ton of FOSS source out there these days, which is freaking amazing, but FOSS also faces an existential threat with licensewashing. Projects like GitHub’s CoPilot are ingesting large quantities of FOSS source to create a derivative work of it, with little or no regard to the original license of the source. Worse, these tools have been remixing these sources to produce further derived works, and have been doing so for over five years internally to some of the companies that spawned them, effectively “washing” the original source license requirements away in the process. This means that the original author’s wishes are being ignored, and licenses such as the GPL which require that derivative works be also distributed publicly start to lose their meaning.

How can they be solved?

We need to test our licenses in the courts and adjust them to specifically cover AI datasets as part of the derivative work argument.

Where do you see difficulties in contributing?

Communication, 100%. It’s not always clear where to open up discussions about patches to software for various projects. Between mailing lists, IRC channels, bug lists, and forums, it’s not always clear where the main team of a project “lives”.

What does a perfect day off look like?

A perfect day off from work, for me, would be no need to go anywhere, and able to spend my creative time entirely devoted to a FOSS project like VICE to implement another big feature like dual head mode in SDL.