The Road to Open-Source

We're starting to put our repos where our collective mouth is.

We’re big fans of open-source software #

We (both in the royal + plebeian sense) benefit handsomely from access to open-source software. At Silicon Ally, we rely on it for pretty much everything, from our text editors and our development environments, to clients’ deployed projects and this very blog. And more generally, the internet (and thus the modern world), is chock-full of open-source components, from your standard Linux servers running Apache/NGINX and MySQL/PostgreSQL to Docker and Kubernetes.

Aside from the ideological warm-and-fuzzies we get from the idea of people building cool, high-quality stuff and giving it away for free, there are plenty of practical, pragmatic, and entirely non-altruistic reasons to open-source software. We discuss our particular motivations in our Open-Source FAQ (which I recommend giving a read!).

And that’s all well and good, but there’s been one niggling inconvenient fact looming in the shadows:

We hadn’t actually open-sourced anything.

Righting the wrong #

I’m happy to say that is no longer the case, as we’ve now flipped the switch on six of our repos, making them available (and appropriately licensed) for anyone’s use. I’ll let the repos speak for themselves, but at a high-level:

• testpgx - Go library for testing against real PostgreSQL databases.
• gqlerr - Go library for handling errors in GraphQL servers.
• cryptorand Go library for easier secure random number generation.
• rules_gqlgen - Bazel rules for auto-generating Go libraries for GraphQL resolvers.
• testsops - Go library for testing against Mozilla’s sops tool.
• idgen - Go library for generating random identifiers.

Aside from just publishing the code, we want people to actually use and benefit from these libraries. To make that more likely, our focus is on shipping high-quality, well-tested, well-documented code, and setting user expectations appropriately for how it’ll change and be maintained over time. With that in mind, we’ve published some guidelines that we’ll adhere to for any project we open-source.

Some observations #

An astute observer may notice that most of these are libraries for the Go programming language, which is what we use for developing all of our backend systems and tooling. A future blog post will detail the software stack that we default to when building a new project.

An even more astute observer may notice that these libraries were all built as part of our ongoing work for Adventure Scientists. This is one of the things we’re really excited about as nonprofit software developers, the ability to share reusable components built as part of a project for a specific client. While it wouldn’t be impossible to do something similar in the for-profit space, prospective clients might say something like:

“But I’m paying you to build software for me, why would I give it away for free??”

And of course, that’s a perfectly reasonable argument. It’s the combination of our nonprofit-friendly pricing and the general mission alignment between us and clients that makes the idea more palatable (or maybe even desirable!).

The start of something good #

We’ve got a bunch more projects in our open-sourcing pipeline, ranging from accessible color palette generation to embedding reverse proxies in a development server. If you’re interested in keeping track of our open-source efforts following us on GitHub is likely the best way to do so.