Building a Successful Open Source Community as an End User Company

Published in

Intuit Engineering

8 min readOct 7, 2021

This blog post is co-authored by Henrik Blixt, Principal Product Manager, and Kareena Hirani, Software Engineer in the Argo team at Intuit.

Open source has a lot to offer for end user companies. By contributing projects to the community, you can tap into a world of new ideas and coding resources to fix bugs, accelerate innovation, and foster experimentation. At the same time, a commitment to open source makes a tech company more attractive to talented engineers and helps build a culture of collaboration across your company.

It’s no wonder end user companies like Apple, CapitalOne, Mitsubishi UFJ Financial Group, Salesforce, and The New York Times have made open source a top priority — and why it’s a core strategy for accelerating developer velocity here at Intuit.

As a CNCF Gold End User member, Intuit is an active contributor to the open source community with a variety of CNCF projects in production and 75 open source projects on GitHub. We’ve built a modern platform in the public cloud to accelerate developer productivity for our TurboTax, QuickBooks, Mint and Credit Karma products, which serve approximately 100 million consumer, small business, and self-employed customers worldwide.

In this blog, we’ll share our experiences and lessons learned with the Argo Project, and how we’ve made open source a success for our business. For a deeper dive, you can join our session on Friday, October 15. Also, plan to visit us at Booth #E1 during KubeCon/CloudNativeCon North America 2021 and learn more in six more Intuit sessions at the show! (See full schedule later in this blog.)

Argo and Our Community

Among our many open source projects — including 50+ Intuit repositories on GitHub — Intuit is probably best known for Argo, a set of Kubernetes-native tools for running and managing jobs and applications on Kubernetes. Argo actually encompasses four independent projects: Argo CD and Argo Rollouts, which help teams using Kubernetes and containers; and Argo Workflows and Argo Events, which help companies. Over 200 companies across industry verticals and geographies are already using Argo to support their development and core businesses.

We’ve been thrilled by the participation that Argo has attracted across the open source community. We currently have over 18,000 stars, nearly 4,000 contributors helping out the project in various ways, and almost a thousand contributing code to one of the four sub-projects.

Deciding What to Open Source

When you’re deciding whether to open source a given project, a few considerations can be helpful.

To begin with, consider whether it will provide value to the broader community by solving a problem that many other people have, or is it narrowly specific to your company and your situation? You’ll have a hard time getting people to work on or adopt a project that doesn’t fit their own use cases, and it might not benefit much from community interaction anyway. Does it serve a short-term purpose like Kubernetes migration, or can it continue to drive value over time without becoming obsolete, like the continuous deployment and progressive delivery that Argo addresses?
It’s also essential that you’re prepared to dedicate time and commitment to the project. For an individual, that means getting approval and backing from your managers to make it a full-time effort. As a company, you’ll need to allocate funding for full-time engineers for the project.
The best candidates for open sourcing are projects that offer a unique solution to a problem that hasn’t been addressed before. That makes it more likely to benefit the broader ecosystem, as well as avoiding the kind of politics and unnecessary competition that can invite friction in the community.
A project that’s modularized and easy to integrate will simplify maintenance while allowing its components to be used easily with other open source projects. We intentionally built Argo to have different building blocks like continuous deployment, progressive delivery, workflows, and orchestration that are easy to integrate as one of the many tools that people use.
Finally, mature internal projects are a great choice for open source. You know they work in production, they have a lot of active internal users, and there’s an existing rigor in releases, patching, and updating. One reason Argo CD and Argo Rollouts have been so successful is that they’re essential for Intuit’s modern SaaS platform, which gives us a strong incentive to continue to innovate and improve them.

Whatever project you choose to pursue, make sure to keep things simple for users in the community. Provide quick-start guides, easy-to-follow documentation, and a way to install it and start using it right away.

The Pros and Cons of Being an Open Source Maintainer

Being a maintainer of an open source project has tremendous benefits. The community is always generous with their ideas, features, and bug fixes, and they can offer a lot of fresh perspectives about use cases across diverse fields, which can enhance a project’s utility. Being part of that community is also highly rewarding in the experimental spirit and idealism they bring to the table. They’re not just in it for the money — they’re working to benefit themselves as well as the community, and they love being part of something bigger. That kind of passion can be infectious.

At the same time, it pays to stay grounded. Passion doesn’t always translate directly into usable code. You have to have careful guidelines to make sure contributors meet requirements for testing and coverage, and that they create issues and greenlight features with you first, before providing a pull request with code you can’t approve because it doesn’t fit the roadmap. The fact that contributors are performing a labor of love also means that they’re under no obligation to help maintain the project for the long term. If they contribute a feature that they’re no longer able or inclined to maintain due to a change in job or life circumstances, that can create a problem for you as the maintainer.

Defining Goals and Measuring Success

As with any undertaking, it’s important to have a clear sense of your objectives for an open source project. That might be defined as reaching a certain point of maturity or adoption for the project itself, or it might mean achieving a goal for your company, such as going through a technology transformation, building a brand as an open source leader, raising your profile in the community to attract new engineering talent, or just enhancing your reputation. Your goal can also be to solve a specific internal problem, whether by engaging with an existing project that fits your use cases or starting a new project.

The goals you set will help you internally justify your work on the project, and it will also help you identify the right metrics to measure your success, whether number of stars, user adoption, code in production, cost savings, increased internal adoption of open source, and so on. You can take these measurable benefits to your leadership to show why you’re investing in open source and how it’s paying off for the business.

Gaining Momentum and Reaching Maturity

Building a strong open source community around your company’s projects calls for sustained effort as well as patience. In our experience, it takes one to two years to build a following. You have to commit to evangelism to build a user base and to build credibility with the community, including blogging, holding community meetings, and attending conferences. You’ll also need to provide lots of user support, which means answering questions, contributing to forums, doing timely bug fixes, and helping users onboard your technology. Otherwise, users will move on to another project if they don’t feel adequately supported, and you may not get a lot of engagement at first, but keep trying and really commit and also leverage related communities.

As your project gets more mature and more users or companies use it, you’re eventually going to run into the question of higher-level support. A lot of enterprises are still not comfortable with an open source model where you either fix things yourself or ask the community to help. They want someone who’s got an SLA backed by monetary penalties. In our case, we’ve had good success engaging with vendors who offer commercial products based on Argo. That gives us someone to recommend when an enterprise comes and asks who they can pay for formal support.

It’s exciting to reach this point of maturity with Argo. We’ve incubated with CNCF, and we’re currently working through their maturity and graduation processes by standardizing our governance, membership responsibilities, release processes, best practices, security assessments, and so on, which is important for building a project that people will trust. The foundation is also a great resource for marketing the project to the open source community, which can be more difficult for an end user company than for a vendor with technology as its core business.

We hope you’ve found this blog useful and inspiring. It can take a lot of work to build an open source community for an end user company, especially in the early stages, but it’s incredibly rewarding as well — as an individual, as a business, and as a member of this global movement.

We hope you’ll join us to learn more at the following sessions during KubeCon/CloudNativeCon in Los Angeles, California. And, be sure to register for our inaugural ArgoCon 2021, a virtual event hosted by Intuit, RedHat and CodeFresh on December 8, 2021.