Developing open-source software full-time

For three years, I’ve been working full time on Silverstripe CMS, the open-source project. Before I started work at Silverstripe Ltd, I had been developing projects with Silverstripe CMS for years.

The last three years have brought their share of exciting work and opportunities. Above all, it led me to rethink how software development can work in different contexts.

I got introduced to Silverstripe CMS working for Firebrand in Dunedin. At first, it was mostly typical digital agency work, jumping from project to project trying my best to find elegant ways to address specific problems within a given timeframe. This was a fun experience, exposing me to a variety of challenges in multiple areas.

Over time, I started attacking more substantial pieces of work and noticed that we were solving similar problems across multiple projects. This is where Silverstripe CMS modularity started to shine for me. Soon, I was building new modules to encapsulate common features we were using across multiple projects.

Working in an office embracing open source was very rewarding. Many of our in-house modules got published on GitHub for others to freely use. This was my first foray into open source. Many of the lessons I’ve learned building those first simple modules, I’ve carried with me in my work at Silverstripe.

I’ve learned how thinking in abstractions can make your code more reusable across multiple projects or how incremental improvements in a shared module can benefit multiple clients and cut cost overtime. It also taught me the basics of open-source project management like the importance of adhering to semantic versioning.

Obviously, my digital agency experience was an asset when I started working at Silverstripe Ltd. Having an in-depth knowledge of Silverstripe CMS, but also of other frameworks like Laravel or CodeIgniter, allowed me to hit the ground running and make useful contributions to the project immediately. My experience building literally hundreds of small to medium scale Silverstripe CMS sites also came in handy and allowed me to bring different perspectives to the team.

Still, there are some challenges I didn’t fully appreciate until I had been working at Silverstripe for several years.

For one thing, the full breadth of use cases Silverstripe CMS has to accommodate is staggering. When making a decision about the CMS, you have to consider use cases from simple brochure sites with a few pages to massive applications with hundreds of Content Editors. Some changes might appear anodyne when tested at a small scale but could make the CMS crawl to a halt when thousands of records are thrown at it.

We also have to accommodate a multitude of Developers. Some devs work on the cutting edge and challenge our preconceptions of what you can do with Silverstripe CMS. Others are more risk-averse and concerned with bug fixes, stability and security. There’s always a tension between developing a product that is forward-looking and helping legacy users come along for the ride.

Being a small team, there’s also a concern about making sure that we allocate our resources judiciously. There are way more cool ideas out there than there’s Developer time to implement and maintain them. So an important part of our work is to validate which of those cool ideas will provide the most value and are most likely to be embraced by our Content Editors and Developers. Sometimes we have to say “no” to interesting pull requests not because they don’t provide value, but because they don’t provide enough value for us to warrant maintaining them long term.

The biggest transition for me came from switching from an environment where open source was a side consideration or a hobby, to one where it’s a full-time job. When you’re not providing any formal guarantees, you have a lot more freedom to cut corners and make mistakes. It is exciting to get a pull request raised against your little projects or otherwise discover that someone out there is actually using it.

When you switch to working on an open-source project full time, your priorities shift:

• You start caring a lot more about regressions and having formal processes to detect them;
• New GitHub pull requests and issues come in every day, so you need to have procedures to triage them;
• You have formal commitments about backward compatibility;
• Security issues need to be handled with care and discretion.

Even so, the initial excitement I felt doing my very first open-source project remains for me to this day. I take great pride in knowing my day-to-day work contributes to nationally significant projects like the NZ Covid-19 website or big businesses like banks and airlines.

It’s also exciting to be tackling a metaclass of problems. Some of the most challenging problems that land on my desk require us to push back the boundaries of what Silverstripe CMS can do. One of the benefits of working for Silverstripe is that we are both developers and users of Silverstripe CMS. Many of the innovations in Silverstripe CMS start off as problems that have an immediate impact on our clients. The solutions we come up with are then merged back into Silverstripe CMS and the benefit flows out to the entire Silverstripe CMS ecosystem.

Above all else, I’m thankful to work with colleagues who are subject matter experts and who, each in their own little way, contribute to making Silverstripe CMS a little bit better each day.