Open source builders: Lessons learned
This two-part article series is based on recent interviews with Alex Casalboni, Senior Technical Advocate at AWS, about his project AWS Lambda Power Tuning; Olaf Conijn, Principal Architect at Moneyou, about his project that is helping users more effectively build infrastructure; and Liz Rice, VP of open source at Aqua Security, about her work within the Cloud Native Computing Foundation (CNCF).
In part one, I dug into how three open source builders got their starts. In part two, I find out how they approached building in the open and the lessons they learned along the way.
Check out the full videos to find out more about Casalboni and Conijn and their open source projects:
Building in the open
One key takeaway from the three interviews is that these builders didn’t set out to build large communities for their projects. Rather, they wanted to put their code out into the open to see if it would help anyone else.
Olaf says that after putting his project on GitHub, in the beginning he did not try to market or promote his project. For the first few months, he worked on it with developers within his company. A visit by AWS Serverless Hero Yan Cui led to Olaf sharing work he was doing and discussions about interesting projects he was working on. Soon after Yan’s visit, interest in the project grew, as did contributions to it. Olaf’s experience is that community influencers, such as Yan, can help raise awareness, promote, and grow a project.
Alex took a different approach with his open source project and started raising awareness by talking about it on social media channels, writing blog posts on different sites, and discussing it at technical conferences. He was looking for contributors.
“In my experience, most projects are grateful and open to new people who want to take part,” Liz says. “Most projects have contribution guidelines and may also label issues with terms like ‘good first issue’ to help you figure out how to get started. Lots of projects also have Slack channels, email lists, or similar communication options where you can ask questions and make sure you’re on the right track.”
Steering the project direction
One way in which projects benefit has been the external feedback and questions that project maintainers had not originally anticipated. Olaf says he enjoys the questions he receives and seeing where the answers help take the AWS Organization Formation project. He says that one of the main project contributions has come from people providing use cases, which has helped steer the project direction.
Being able to influence the direction open source technologies take is a big reason many individuals and companies join the supporting organizations, such as open source foundations. Liz says that the Technical Oversight Committee (TOC) at the Cloud Native Computing Foundation (CNCF) is the team that sets the technical direction for the CNCF.
“Historically most contributors and community participants came from vendor companies—either the large cloud providers or those offering cloud-native products and services,” Liz explains. “These days, as Kubernetes and cloud-native adoption has taken off, we increasingly see participation from what we call ‘end user’ companies—those employing cloud technologies to further their business goals.” She says those companies get involved so that they can influence the technology and projects that they care about and that are strategically important for them. “This ability to participate in the development and stewardship of the technology they rely on simply wasn’t possible before open source, and it’s one of the great strengths of having a neutral foundation owning the projects,” she explains.
Liz says that a lot of the day-to-day work at the CNCF involves deciding which projects can be accepted into the foundation, and at what level of maturity. “CNCF have sandbox, incubating, and graduated projects, and there are both technical and non-technical criteria for each level,” she says. For example, Liz says that the committee expects projects to have open governance and to be vendor-neutral. “We’re also there to provide advice and guidance for projects, with a light touch,” she says. “The TOC members are all doing this role alongside their full-time jobs, so we rely on a lot of help and expertise from other members of the community, and this is now formalized through CNCF Special Interest Groups (SIGs).”
Community lessons learned
At a technical level, Alex said one of the key things he fixed on his project was to address the lack of testing. He wanted to make sure that people coming to the project could see that the code was being written properly and in a way in which they could trust. Alex did not have this for the first year, but he now has 100% test coverage.
Alex also recommends project leaders fight that internal urge to fix everything themselves. He says trying to address issues and making all the pull requests is tempting, but getting better at delegation and trusting community contributors is important.
Learning open source project norms is also something Olaf would have done differently when he launched the project on GitHub. He says future projects will be set up more aligned to open source standards from the beginning.
“There is this romantic idea that you just create open source software in your kitchen and become a startup unicorn, but it doesn’t happen like that.” Liz says. She explains that a project needs a business model—and customers willing to pay for what you provide—in order to become a business.
“As I’ve learned in a career involving startups—both successful and failed—turning a software project into a business requires a lot of different skills and a good dose of luck,” Liz says. “The reality is that most people who make a living out of open source software do so as an employee of a company who pay them to do that work,” she adds. “For example, the CNCF is funded by hundreds of companies, who also pay members of their own workforce to put engineering, documentation, community, and education efforts into open source projects. Just like we do in my team at Aqua.”
Alex, Olaf, and Liz continue to work on existing and new open source projects. Olaf is busy recording webinars, helping his community understand and know how to use his open source project, AWS Organization Formation. Alex continues to release updates to his Lambda Power Tuning project. And Liz says Aqua Security just released a new open source project called Starboard, which they describe as a Kubernetes-native security toolkit.
Are you an open source builder?
In this series I hope to uncover the stories behind the open source projects and help understand what makes open source tick and inspire more builders to get involved in open source.
If you have an open source project, are an open source developer, or are involved in open source projects and communities and want to take part, please get in touch.
Feature image via Pixabay.