Ordered list of blogs will go here with a widget
Towards the end of the year some will take some much needed time off to spend with friends and family. Others, such as myself, will take the opportunity to get things in order before the end of the year. In particular, this is when I will work on personal projects such as the Knative C runtime. More recently, something I worked on for TriggerMesh that would turn Debezium's streaming changes into a Knative event source is a modification to Debezium to expose an HTTP client to stream the events to a targeted webserver for consumption. It was while working on this, and reflecting on the recent Log4j vulnerability and associated commentary, that I started thinking about my software projects and personal role in the open source community as well as others at large.
For context, I grew up with the popularization of the hacker culture from the movie Hackers being released, Kevin Mitnick being imprisoned and still awaiting trial. Through that I was exposed to Linux (in the v1.2 days), Solaris 2.6, and Minix as the only unix that would run on my pokey 286 and got me into exploring operating systems and some of the GNU stack. The freely available tooling and source code gave my curious mind a lot to much on and learn. This went into operating systems and Linux/Minix in addition to FreeBSD. Going into college, I clung onto the ideals of the free software foundation, open source, and being in an academic setting that fostered it. I was young and idealistic latching onto the egalitarian approach to software.
Even in that environment I never really felt comfortable contributing code back, and suspect it is the same thing that prevents everyone from being a potential author where your work is out there exposed for all of the benefits and flaws. I think it was the broadly accepted idea that open source can allow for millions of people to use your software, watch for vulnerabilities, and contribute to said issues. It is safe to say the goal for most engineers is to do something that can contribute meaningfully to others, and open source provides the quickest way to do that.
When I went to work for Sun Microsystems supporting Solaris, and even spent the nights/weekends working on an early stage startup, my opinions had started to change. Github was starting to gain traction, but I kept most of my personal projects in-house. It took a conversation with a boss where I was pitching an idea where he commented that I was free to develop it in my spare time even though it was something that would have direct benefit to the company. Having heard far too many horror stories regarding intellectual property ownership I held to a strict line between what is done on personal time vs company time, and given the little spare time I had at the time, it became apparent that one's passion could backfire. It was then I became more mercenary towards my approach of software and how I contributed towards open source. In Heinlein's The Moon Is A Harsh Mistress, there is an expression:
TANSTAAFL - there ain't no such thing as a free lunch.
I've been fortunate where some of my engagements over the years had me working on open source projects ranging from small to large. Some being companies built around open source like Gitlab, and others that have been adopted by large organizations such as the CNCF. However there are others where work had started and later abandoned as interest and other paying clients came into play. Regardless of the project, the only time I really worked on them was when there was someone willing to pay as I've had little time to myself these days save for the few precious days at the end of the year.
The important thing with software is that it is much more than just writing code. There's the filing and responding to issues, documenting what you've done, fielding questions from your users and peers. This work will grow as the project grows in scope, contributors, and users. Regardless of whether the developer or maintainer is paid or not. At what point does the developer's contribution become more than just a personal project released to the world at large? When does it stop becoming just a hobby or a volunteer effort? At what point are the users responsible for contributing back to the software they've been using freely over the years and have event built their business upon?
Those were the questions running through my mind as I was working on my project this week, and thinking about the most recent Log4j security incident and the few maintainers who manage the project solely in their spare time. Thinking about what happens when your software is not only used by a large number of people, but when a critical bug is found. There is no dedicated support staff, SLAs guaranteeing a time for when a response can be expected let alone a fix to be in place. The biggest advantage of open source is that anyone can make a contribution and someone skilled enough can submit a fix, but it still needs to be reviewed and accepted by the maintainers for it to be packaged and distributed. It is this last part that is key as this distribution mechanism is how the various package managers from Redhat to Maven and NodeJS know when a new version is out and ready for installation.
What other options exist to ensure the maintainers of critical projects can get properly compensated without burning out? Essentially, this boils down to four approaches based on size:
Each approach has their pros and cons, but it comes down to a tradeoff between ownership, flexibility, and influence. It depends on the project and the maintainers.