Surviving Open-Source

There is little more defeating as a software developer than bug reports that don’t seem to end. Just one day, you pray, one day without a report. But it never comes.

Do you know how I know not a single startup CEO is faring any better than you in life or happiness? Bug reports. The fact that we all have them puts us in the same place. Just as a scream let out by your dog after you step on his paw lets you know that you and your dog feel the same kind of pain, the fragility of software lets us know that everyone in this industry feels the same shitty way when a customer reports your product isn’t working.

But to a large degree, this pain is self-inflicted. We accept that the nature of software is to bloat, as if it were writing itself, and absolve ourselves as maintaining software the only way possible.

Software bloats largely due to lack of discipline. And because idleness makes us itchy. What’s the fun in releasing a project that does one task and does it well, and is thus always hovering in a finished state? Where’s the growth, the work, the excitement and enrichment? With Silicon Valley salaries rising faster than cryptocurrency prices, companies do not pay their engineers to report that “the work is done, taking the day off. The result is work for the sake of work, and eventually, bloat and fatigue.

Being an open-source project maintainer usually means a different set of circumstances: you already have a full time job, likely a family, and definitely a pile of bills. Your open source project started as a way for you to escape, to build something new and explore new technologies. But what happens next can ruin your life.

In the beginning of course, your project starts simple, and does exactly that one thing other people are desperately looking for. And they come to your project precisely because it is so focused and simple to use. You get your first GitHub issue and you’re ecstatic that you’ve received some engagement. Eventually however, this or that user tells you that your framework does not do this one specific task that is uniquely relevant to that specific context. And you both agree that it would be simple enough to build in. So the user submits a pull request and you merge it. Look at that. You’re growing. How wonderful! Issue after issue, your project learns new tricks and does more useful things to more applications around the world.

All the while, the bug reports never stop flowing in.

Just one day. You pray for of peace, but you won’t get it. You’ve upset the simplicity gods.

It is a core tenant of software development that functions and classes that do one thing and one thing only lead to more manageable and sustainable codebases. Yet we abandon all such principles at the higher level. In building Standard Notes, localStorage was not sufficient in storing user notes. So I began looking into IndexedDB. The documentation stated that getting started with IndexedDB might be difficult. So I sought open source libraries that might make it easier. One such find was Dexie, which called itself a “minimal IndexedDB library. Needing to keep the Standard Notes codebase lean and small, minimal was exactly what I was looking for. But as I began looking through the files, I uncovered an unsettling truth: several files with thousands of lines each and hundreds of functions. That would be tens of thousands of lines of code that my application would need to depend on for its survival. I was stunned. How could you possibly call this minimal?

You can easily see the story here: started minimal, then open-source took its toll. This user wants it to do that, that user wants it to do this. Thousands of independently simple and reasonable requests compound into the dreaded software bloat, better known as the slow kiss of death.

I ended up writing my own IndexedDB wrapper in 143 lines of code. And it did everything I needed it to do. Without issue.

While Standard Notes has evolved from being just an open-source encrypted notes app into a functioning entity of its own, it is still open-source software at heart. And with it come the endless feature requests and issues. But I’ve already decided. I’m saying no.

Saying no is impossibly hard, especially as a small project. You’re grateful that other people are taking the time to critique your code, and don’t want to scare them away with a conversation-ending “no”. But I’ve learned that saying no is the only way to survive. Because the most useful thing you can build is something that does one thing and does it well, and survives long enough that the world truly has the chance to benefit from it.

Instead, when you feel the urge to work on something or to write more code, create a new project, and start coding there. You can even use your previous projects as building blocks.

When running an open-source company, this is doubly important. Your products will pivot tremendously during the discovery phase of your startup, and you may never even leave discovery. By structuring your applications and codebases as single task building blocks, you’re able to maneuver quicker while maintaining stability and performance.

Most importantly, keeping your projects simple allows them to survive for a longer period of time. Software that degrades in less than a year doesn’t have to be the norm. And if you’re bootstrapping your company, one of the smartest moves you can make is investing in simplicity. Not only will your engineering costs be drastically lower, but customer support costs as well. And while bug reports are an inevitable part of software development, they can be managed.

Ultimately, simplicity means happiness. For you, your team, and your users.

Look at me. I wrote this post today. What could you do with less bug reports?

If you’re curious to learn more about Standard Notes, an open-source notes app that focuses on simplicity and privacy, visit https://standardnotes.org.