Implementing good advice
- 1 minDuring a catch up with a friend earlier this year, a sage piece of advice was given.
Don’t start an open source project. Contribute to someone elses.
Releasing and maintaining a piece of software is a hard and often thankless task. APIs change over time. Issues get submitted. Intended uses morph as industries shift. All of these create unpaid work for the maintainer.
FOSS is intended to alleviate this strain on the individual, although often falls short. Anyone can, in theory, contribute to any project to introduce features, improve the UI, and squash bugs.
When a feature in the Audiobookshelf android app moved away from my usage pattern, I decided to take the advice and make a contribution. Whist my original request was turned down because of longer term plans, I did manage to help shape the UI within a section of the app.
The changes are only a small contribution. I’m certain it would have been quicker for the maintainer to implement than me. Regardless, I made my first pull request to an open source project. . . a goal I set years ago back in uni, charting my path towards becoming a software engineer.
Every time my partner and I use the app, we benefit from the code I wrote. So does everyone else. I was able to go through the git pull request process from start to finish on a random project, with strangers. Something that seemed so daunting all those years ago.
For bonus learns, I’m now maintaining a personal fork of the project. I’m an edge case in terms of how I use the app, when considering the wider user base. The original request was to support that usage pattern by prioritising offline media in a connected state. The changes made the app painful to use.
Thankfully, I have the skills to shape the app to suit my needs, whilst still contributing upstream where it’s welcome.
I guess I’m a smart Cookie too.