How SPACE Kickstarted Our Internal Open-Source Software

SPACE is LaunchPad Lab’s internal innovation program that allows us to explore, innovate, create, and solve problems. It also provides opportunities for our team to live our company constants and apply these experiences back to our client engagements through product, design, and technical expertise.

While primarily focused on experimentation, this program has been crucial to our company’s evolution and has enabled teammates to become pathfinders for our present-day core competencies, tools, and processes. Affectionately called “missions,” these experimentations have undoubtedly influenced us and in particular, we like to highlight those that produced tangible “spinoffs“ — projects with direct benefits and impacts to our client work. Next, we’ll discuss one such project that led to the development of our own internal open-source ecosystem.

Why Rebuild the Same Thing?

This is a question we consistently ask ourselves — particularly for the developers on the team who are trained to identify patterns and build reusable code. As a consultancy working with a myriad of clients on diverse projects, we are uniquely positioned to see many problem sets. Naturally, this helps our team have a more sizable dataset to uncover the patterns.

Without necessarily being cognizant of the potential impact, a few team members began to experiment by building reusable code to generate a blog — a common feature set we have built.

Getting Real Fast

As the team got to building a blog generator they worked to identify what is unique about each blog we’ve built versus what is consistent. Editing features and database modeling settled into very common patterns while the content display from a styling and layout perspective varied. This led the team to standardize certain things but allow intelligent defaults to be overridden where appropriate.

Version 1 of this experiment came to fruition as part of our quarterly demo days in a gem called Fuel.

The launch was met with much internal excitement that carried over to the public launch and use of the gem on a couple of our client projects. Immediately we saw reduced development effort and more robust feature support as a default for projects leveraging Fuel. And with each project deployment, we further refined the features, such as self-hosted images, of the blog generator to be even more impactful.

Gaining Momentum

While Fuel was successful in its own right, its larger and longer-term impact was kickstarting a flurry of developing reusable code baked into open-source libraries. As subsequent demo days came up, we saw several new libraries, a snapshot of which include:

• Decanter: A sanitizer and formatting library for incoming data with a total public download count eclipsing 120K
• Token Master: Easy management of token-based flows for Ruby apps
• LP Components: A set of reusable React components
• Client Template: Template app for React/Redux SPAs

The Spinoff

As we zoomed out a bit, the trend and positive impacts on our client projects with these libraries became clear. Through the course of library-building, we had built the skillset of proper abstraction — balancing opinionated code with being open to overrides — in such a way as to maximize development time reduction while also ensuring its applicability to many use cases. We took the next step to formalize these libraries and other development best practices under the title of OpEx (short for Operational Excellence) — an ongoing working group dedicated to improving development speed, code quality, and developer experience at LaunchPad Lab (learn more). With this more tangible structure, we’ve been able to more continuously invest time and focus into improving existing libraries and creating new ones to accelerate improvements in our client work.

Now with this working group going on 6 years strong, we’ve seen how the more formal investment and attention as a complement to our demo days have accelerated our library and process improvements.

The Impact

The influence on our day-to-day work and client projects manifests along quite a few dimensions — both quantitative and anecdotal. We estimate that over the past 2 years, ~90% of our project work has leveraged the code and processes published by the OpEx working group. Developers on our team cite expedited builds, more robust and tested features, and more time to focus on unique aspects of a project, almost feeling supercharged on their client project work.

The success to date is certainly worthy of recognition and praise! However, one of OpEx’s core directives is never reaching a state of done — always looking for ways to enhance and embrace the new patterns emerging within our team and the broader industry. We have certainly seen ebbs and flows in the activity focused on stability versus net new libraries — but the trend is forward.

What all started as a single side experiment one given demo day has transformed into a sustainable feedback loop to improve our best practices, develop reusable code, and knowledge share across a growing team of individuals and experiences. While we can rarely predict where and how the new “spinoff” will occur, we know that by continuing to put energy into our SPACE program we can foster an ecosystem that reliably produces enhancements to our work on client projects — and have fun while we do it!

×

Subscribe to Our Newsletter

If you made it this far, you should sign up for our monthly newsletter. Get our latest articles and insights delivered each month.

First Name*

Last Name*

Email*