This post originally appeared on the FINOS Community Blog. The author, James McLeod, is the Director of Community at the Fintech Open Source Foundation, a project of the Linux Foundation. You may also want to listen to the Open Source in Finance podcast.
I often talk about “engineering experience” and the importance for open source projects to provide fast, easy and impactful ways for open source consumers to realise return on engagement. Just like e-commerce stores that invest in user experience to encourage repeat sales, successful open source projects provide a slick installation, well written contextual documentation and a very compelling engagement model that encourages collaboration.
This article is focused on the “engineering experience” related to automation and deployment, but future articles will also cover providing an engaging README.md, contextual documentation and the workflows needed to engage new and experienced open source contributors.
ENGINEERING EXPERIENCE PROVIDES DAY ZERO OPEN SOURCE VALUE
The risk of ignoring an open source project’s “engineering experience” is the project becoming a lifeless repository waiting for a community to discover them. Imagine the questions that have been answered in dormant repos that could be solving real world problems if engagement was easy.
At FINOS we’re driven to provide day zero value to financial services engineers looking to utilise FINOS open source projects. This philosophy is demonstrated by FINOS projects like Legend, Waltz, Perspective and FDC3 that engage in open source methodologies for ease of installation.
Without engaging in a healthy “engineering experience”, engineer teams might find themselves working through reams of documentation, setting flags and system settings that could take days to configure and test against each and every operating system on their route to production.
The scenario highlighted above has been mitigated by FINOS projects Legend and Waltz by using Juju and Charms, an open source framework that enables easy installation and automated operations across hybrid cloud environments. Without Juju and Charms, Legend and Waltz would need to be manually installed and configured for every single project instance.
By engaging Juju and Charms, Legend and Waltz are shipped using a method that enables the projects to be installed across the software development lifecycle. This accelerator provides a positive “engineering experience” whilst increasing engineering velocity and saving development and infrastructure costs.
From the very first point of contact, open source projects should be smooth and simple to understand, install, deploy and leverage. The first set of people an open source project will meet on its journey to success is the humble developer looking for tools to accelerate projects.
Take node.js and the various ways the node ecosystem can be maintained. I’m a massive fan of Node Version Manager, an open source project that enables the node community to install and traverse versions of node from a simple and easy to engage command line tool.
Node Version Manager removes the requirement to install, uninstall and reinstall different versions of node on your computer from downloaded binaries. Node Version Manager runs on your local computer and manages the version of node needed with simple bash commands.
With Node Version Manager provided as an open source tool, the further “engineering experience” of yarn and npm can be explored. Which enables FINOS projects, like Perspective and FDC3, to be installed using node.js to accelerate the financial services industry with simple commands like yarn add @finos/perspective and yarn add @finos/fdc3.
The chaining together of “engineering experience”, that removes the pain of manual configuration by leveraging containers and command line automation, not only invites experimentation, but it’s contributed greatly to the exponential success of open source itself.
As the articles move through the different ways to engage open source communities to make open source projects successful, it would be great to hear your “engineering experience” experiences by emailing firstname.lastname@example.org or by raising a GitHub issue on the FINOS Community Repo.