The vast majority of open source projects attract a small handful of committed contributors. It has always been thus. The best of such projects manage to do much with a little. SolveSpace is one such example, and much of its success stems from a particularly committed project maintainer who goes by Whitequark. While she has done significant work to improve the project’s existing code, some of her most important work–and, by extension, some of the most important work any project maintainer can do–is simply to ensure new code doesn’t break old code. It turns out that’s not simple.

The importance of continuity

John Byrd is credited with a great statement: “Good programmers write good code. Great programmers write no code. Zen programmers delete code.” It’s perhaps an overstatement, but the idea behind it is spot on: As a code base accumulates cruft over time, great engineers will invest the time necessary to strip the code of technical debt. As DJ Walker-Morgan once put it, “Deleted lines [of code] are the final burn down of the ground where tech debt built.”

It turns out that this concept of clean up and stewardship is particularly important in open source project leadership. Talking to Whitequark, while she writes less code these days and reviews more, she stressed that her job is to “ensure the long-term viability of the project.” For some projects that could include finding funding, or attracting new development talent. Whitequark does those things. 

SEE: How to build a successful developer career (free PDF) (TechRepublic)

But she does something more: “I review the code submitted by contributors and co-maintainers, and make sure these changes won’t come back to bite us later.” (Emphasis mine.)

Over the years, she has used her systems programming background to “rework some of the most challenging parts of SolveSpace,” including making it HiDPI-aware, Unicode-aware, internationalizable, testable, and implementing a UI abstraction layer that allowed for a coming Web Assembly port. So she’s done “real work,” as some might see it. She’s put the project on better footing to attract users and developers. 

In so doing, she stressed, she’s guided by one core principle: “Done is better than perfect, but
broken tomorrow is worse than not done at all.” As such, she continued, though “Slow development can be frustrating to users, and [might] alienate a vocal minority, … [if] SolveSpace
is [to remain relevant, she needs to] leave it better than how I found it, even if it means a lower pace of improvements.”

When backward is actually forward

We’ve seen this same principle applied in other projects. Apache Cassandra is a good, recent example. In talking with Cassandra insiders, there was a point when stability took precedence in the Cassandra community, with Apple, Netflix, and other big users of Cassandra joining forces on this goal as users got stuck on version 3.11.

As cool as it sounds to issue yet another release, Cassandra users were tiring of revalidating their databases every two months when a new release hit. The Cassandra 4.0 effort has been a broad-based, community effort to get the Cassandra house in order.

Which brings up an interesting point common to SolveSpace, Cassandra, and other projects: Often the best stewards of a project are those who use it. Whitequark doesn’t simply work on the SolveSpace project: She needs an open source, parametric 3D CAD program to build flanges and other physical parts. Given how widely Apple uses Cassandra, it needs to ensure the database is rock solid. Such careful attempts to ensure these projects take it slow are the best way to ensure the resulting businesses or projects can move fast.

Disclosure: I work for AWS, but nothing herein relates to my work there.

Developer Essentials Newsletter

From the hottest programming languages to the jobs with the highest salaries, get the developer news and tips you need to know. Weekly

Sign up today

Also see