 Hi everyone, and welcome to this session about building a successful open source community as an end user company. My name is Henrik Flix. I'm a Principal Product Manager at Intrid with a long history in open source, starting in the mid-90s with Linux, I was a stacker for a number of years, and now lately I've been focusing on Kubernetes and Argo here at Intrid. Hi everyone. My name is Karina Harani. I am a software engineer at Intuit. I work on the Argo rollouts team, which is responsible for progressive delivery of applications in Kubernetes. I've been part of the open source community for the last year and a half. I've been a software engineer for about four years, and I'm really enjoying my experience in the open source community. So just a little background on who we are. I think for those of you that are from the US, you might have heard about us, but we're a US-based Finite company, started almost 40 years ago, and as of this early this year, basically 95% of revenue is coming from activities in the United States, and you've probably heard about our projects, products called TurboTax, and the Personal Finance App Mint, as well as our small business program around QuickBooks. We have about $10 billion in revenue from over 60 million customers that run on our platform, and we've taken this Finite company on a very interesting journey over the last few years where we were a very traditional company running in data centers, a lot of traditional applications, and architecture, to now lately, a fully cloud-native, running a public cloud platform using cutting edge technologies, using Argo, Kubernetes, ServiceMesh, Serverless, and so on. And during this journey, we've also invested a lot in open source. We have over 75 open source projects on GitHub, and we're also a CNCF Gold member. So just a quick recap for those of you that don't know Argo. So Argo is really a set of four different cloud-native projects. We're currently in a CNCF incubator project since April last year, and we have two projects that are more geared towards GitOps with Argo CD, allowing you to do GitOps to get as the source of truth for your application and infrastructure. And then we have Argo Rollouts, which enables progressive delivery with advanced deployment strategies for application rollouts, like blue-green and canary strategies. And then we have two projects that are more on the ML side. We have Argo Workflows, which is a Swiss army knife of a workflow engine that can be used for things like massive job prioritization and automation. And it's currently used throughout our user base and within Intuit for ML data pipelines and various infrastructure automation. And then we have Argo Events, which is an event-driven framework to help you trigger actions when various events occur in extraordinary event sources, very commonly used together with workflows to trigger a workflow when something happens. And just a proof point on how far we have come and where we are today with our Argo projects. We currently have over 18,000 stars, which is almost a doubling since we incubated a little bit over a year ago. We're getting close to 4,000 contributors that are helping out the project in various ways. And almost 1,000 of those 4,000 are actually contributing code to one of the four sub-projects. And we've had a very steady growth, very linear growth for all our four projects. We're growing at a rate between 20 to 30 stars a day. You can see the Argo CD and Argo workflow are growing a little faster than events and rollouts, but all four projects have been very nice, healthy, continuous, steady growth. And quickly about the timeline and how these four projects came to be and how Argo came to be all together. They were incubated at a startup called Aplatics a little bit over four years ago. And as part of the transformation, the platform transformation that I mentioned earlier, and that started into it, was acquired by, sorry, Aplatics was acquired by Intuit to help through this transition. Argo Workforce was currently there with Aplatics as that team started getting heads down and building this new platform for Intuit, the need for something to manage application and the delivery of application was born and that's where Argo CD came out. A little bit later that same year, we had one of our users BlackRock that would be using Workforce for a long time, contributed to Argo events and that made a trio of projects. After Argo CD was put into production and Intuit, there were additional requirements and learnings that led to the understanding and development of Argo rollouts. We needed something that could do progressive delivery and these advanced deployment strategies, but we didn't want to build that into one of the existing projects because when they keep them separate, we'll talk more about it in a little bit, keeping the modular and more as building blocks. So hence, Argo rollouts came out of that. And lately we've been focusing more on polishing and getting Argo as a project mature and are the features that are there, the products that are there, but we also want to make sure that the project itself, in terms of governance, maturity is there. So like I said, we've incubated with CNCF, we're currently working towards graduation and as part of this process, we've gone through a number of steps to standardize our governance, membership responsibilities and things like that. So we're really excited going through the process and hoping to graduate the projects here later this year. So some benefits of open source that we believe are that it helps build better software and we believe that because you have a large community involved with your project, which means lots of different peer reviews, a big variety of ideas and contributions and because the code is completely open to the public, we believe this demands a higher standard of code and also of professionalism, because contributors take more pride in they were in their work, they realize that everyone can see everything, it's a point of pride for them. And another great thing about open source is that we believe it attracts and retains talent. So open source projects are known for being new and exciting using all kinds of cutting edge technologies and there's also a pipeline from being an open source contributor to possibly getting hired by the company who runs the open source project if you contribute frequently enough and provide things like large features and stay in contact with the group maintaining the project. So engineers can definitely get a lot of experience working in the project and they can also get a lot of recognition as well as the ability to work with multiple different organizations, the ability to be exposed to a variety of contributors outside of their company and a lot of great perks like open source events, attending conferences like KubeCon, going to all kinds of different meetups. So it's a very fun environment and we find that talented engineers do want to work in open source. And another benefit that we believe is that open source allows companies to establish a technology brand. So open source projects cannot subsist on marketing magic because the technology is completely public to the world. This helps to build trust with consumers because there are no secrets in the code and because anyone can view and use the technology you put out, they can tell that it actually works. So it can improve the reputation of the company. So when you have a project and you are deciding whether to open source it or not, there are a few questions you need to ask yourself. The first is what you're doing going to provide value to the broad community. So are you solving a problem that many other people have? Or is it something very specific to your company and your situation? People won't be inclined to work on or adopt a project that doesn't fit their requirements. So if your project has very narrow use cases, it is unlikely to build a following. Another thing to consider is the time and commitment. Open source is a lot of work to maintain and you need to put a lot of time and effort into building and sustaining a community. So you have to consider do you have the backing time and resources to make the project successful? We'll cover in later slides just how much work it takes to maintain an open source project and what you need to do. But the important thing to know is that if you're an individual who has an open source project, it's important to have approval and backing from your managers. So you have the time and resources to work on it full time. And if you're a company considering having an open source project, then you need to allocate funding to higher engineers full time. And you need to commit to providing resources even though it can be easier to get funding for vendors with business plans. So another thing to consider is do you have an actual goal or plan with your project or your idea? So is it a short-term goal like a Kubernetes migration or is it a longer term goal? Is it also important to consider, you know, is it a specific problem with the company or is it a problem that many people face and therefore it would benefit everyone to get the community involved? So we believe that with short-term projects like migration, once the migration is over, the project could eventually become obsolete. It's important to invest in a long-term project. So something like Argo, for example. We have sub-projects that deal with continuous deployment and progressive delivery, and those things will always be in need. So it will never really become obsolete at any point. So the last thing you need to consider is will your project actually benefit from community engagement? If it is very specific to your company, then it may not be worth open sourcing because it won't benefit very much from community interaction. So maybe it's better to keep your project simple and not worry about the community's variety of use cases and keep it very specific to your specific company use cases instead, in that case. So what makes a project good for open sourcing? One is that it solves a very specific problem in a unique way. And what's important is that it relieves a problem that is unaddressed with no current solution available. So that will benefit the broader ecosystem. That means that your project is not competing with existing solutions, which could involve a lot of politics and unnecessarily competitiveness, and the community can rally behind you instead of thinking which project they should choose. Another important factor is something modularized and something that can be used and integrated easily. So if you have a very big project with complex use cases, that introduces a lot of dependencies on other technologies and other open source projects, which make it tough to maintain. So if it's modularized, then components of your project can be easily used by other open source projects. So in Argo, for example, we intentionally built it so that there are these different building blocks, like CD continuous deployment, progressive delivery, workflows for orchestration, because they are easy to integrate as one of the many tools that people use. So we also think that mature internal projects are very good projects to open source because you know it works in production. Your company is already using it. It has a lot of active internal users. There's an existing rigor in releases, patching, updating. So for Argo, CD and rollouts, we created it because we believe it's necessary to into its modern SaaS platform. And one big reason it's successful is because we have a strong commitment to innovate and improve it because we also use it and depend on it. So from a maintainer's point of view, here are some benefits of being part of the open source community. Being part of the community can be great. They are very generous. They help a lot with bouncing ideas around. They provide features. They provide bug fixes. And they're very passionate about being involved in various open source projects. They also provide all kinds of fresh ideas and use cases because they come from such different fields that it helps solidify the project's utility across a lot of different types of uses. So it's really rewarding and fun to be part of a community for as someone who works in open source. It's great to have work on something with followers and fans. And it's great to know that so many people are passionate about what you work on and that they actually use it. And external users in open source tend to be very experimental. They tend to be more intrinsically motivated. They're not just working on it for money. They're working on it to benefit themselves and the community, which is great. So in contrast, some challenges of having an open source project is that passion does not necessarily mean that contributors create usable code. You have to have very careful guidelines for contributions to make sure they meet things like testing requirements, code coverage requirements, make sure they create issues and green light features with you first before they provide a PR with lots of code that you are not able to approve because it doesn't fit in the roadmap. So you need to be very careful about making it clear how people should go about contributing. And one issue is that contributors are not obligated to help maintain the project long term. A lot of contributors are very passionate, very great to have involved in the community, but they are not financially obligated. It's not part of their job to continue to be involved in the project. And if they contribute a feature that maybe they no longer maintain when they have a different job or their life circumstances change, then that can create a problem for you as the maintainer. And with internal development, it's structured. It's reliable in contrast to the community, which does not necessarily have the obligation as a bunch of coworkers who work at the same company. So it's always a little bit of a risk. So one thing that's really important in an open source project, and Karina touched on that earlier, is defining what your goals and what the success for your project means. Like what's the end goal of the project? And instead of just saying it's just going to be a forever continuing project, it's really important to set up a goal so you can say, or at least Miles was saying, we've reached this point in terms of maturity, adoption, or whatever it might be. It might be a goal for the company itself, using this as part of the tech branding that we said earlier, going through a transformation, making sure that you build awareness in the community and use that to attract talent and then just build a better reputation for your company. I mean, that might be a goal and you can use something quantifiable, like the number of talent you attract, for example, as part of that tech brand. It can also be solving a specific problem. We know that you have something that needs to be resolved internally and there is a project where those use cases fit in very well. So you start engaging with that project or start a new project to solve those specific features. Once those features are done, then maybe put the project in maintenance mode or if you're part of a bigger project, then maybe start working on a different part of that project or move on to a different project. But at least have a goal of, this is the amount of work we need to complete to solve these use cases or solve these problems. And that will also help justify internally why you're engaging with that project or starting a new project. It can also be something if you're coming more from the vendor side and looking at some of the quantifiable metrics, like the number of stars that I showed earlier or the number of uses that are adopting it in production and using that as a means to gain momentum for an open source project that maybe you are a real base and enterprise offering on at some point. Or it could also be something that our management really likes, like cost savings and driving internal adoption of open source. And in a step of doing that adoption of that open source internally, you might need to add a feature here or there. But by doing that investment in open source, you can take a project, use it in your data center, public cloud or whatever and have cost savings to justify that investment. But then again, you have a goal, you have something measurable. This is why we're investing. It's going to give us these benefits. It's going to give us this value. And then you can take that to the board management, your boss, whatever it is that signs the check and show something quantifiable. Getting the project off the ground, and Karina talked about that a little bit earlier, but some of the key things that we've seen that we've learned along the way, one of the most important one is keeping things simple. Being able, for a user to be able to start using it basically right away. Having quick start guides, easy to follow documentation, a way to install it and start using it right away. You might have five minutes to get the user on board and running. If it takes longer than five minutes or they have a question, then it goes into the next bullet here about user community support. If they fail to get started themselves within five minutes, they have one, maybe two chances of helping them out. And if there's an easy way for them to reach someone that can help them, Slack, get-up discussions, whatever it may be, you have another chance of getting them back on board and getting them to test the product. If you miss both of those, chances are very high that this user is going to move on and try a different open source project or maybe go and figure out it's not even worth it and go and purchase something instead. Once you get more mature and you get more users online or companies using it, you're eventually going to run into the questions of, who do I pay to help me out with the support for this? A lot of enterprises are still not comfortable with an open source model where you either fix things yourself or you ask the community to help. They want someone that has an SLA attached to it with some monetary penalties unless things get fixed within that SLA. So we've had very good success engaging with vendors, having vendors offer commercial products based on Argo, for example. So when an enterprise comes and asks, who can I... Please help me find someone that I can pay to help me support this. We have some vendors we can point to. If you don't have that, chances are they might have to move to something else because they have internal guidance restrictions that require them to have that support. And another thing that's been very useful both in terms of growing the community as well as being a good part of the community is integrating with other projects that helps you tap into other domains and user bases of similar projects that solve an associated use case. And if your project can and is modular, that Trina talked about earlier, the importance of, then you can work with those other open source projects, integrate with them and offer an end-to-end solution by still using those building blocks and let the users seamlessly integrate these open source projects. That also helps you keep that rigor of building it modular and open source. And all this together will help you get to those tens of thousands of stars or user adoption. One thing we've also had good success with is taking advantage of the open source maturity and gradation processes. And that goes no matter which foundation you happen to have your open source project part of. I mean, there are multiple out there. Argo that we have the most experience with is part of the Cloud Native Foundation. They've been very supportive and it helped us a lot with things like marketing, where we as an end user and other individual contributors might not have the marketing muscle to market and brand an open source project. And our vendors are a little bit different. They usually have much bigger marketing machines that they can utilize. But for an end user, marketing something that's outside of our core business is a little bit harder. So taking advantage of those webinars, tweets and the other things that you know that CNTF or these foundations can offer have been very, very helpful. They also help introduce some rigor into the process. Either various tags and working groups that you can go and ask for help. You can present to your reviews and make sure that your releases are following a release scheme that you're doing regular releases and you have just regular release and product building and development rigor. This is really important when you build a project that people will trust. These foundations have also been around for a long time and they have some really good best practices for governance, code of conducts and things like that that they can help you. They have skeleton templates for you can use to easily adopt them and make sure that your project is according to best practices in the community and within those various foundations and make sure that you don't run into an issue down the line if there's a disagreement within the maintainers. And then lastly, these foundations take pride in the maturity and graduation processes. So once you've gone through the process, the community can trust that whatever has gone through this process has been vetted. So there are security assessment and guidelines and procedures that they will help you with and go through to make sure that your open source project is at least as secure as proprietary alternatives or options. So some key learnings from this talk are not to underestimate the time and effort necessary for community building. It takes in our experience one to two years to build a following. You have to commit to evangelism, which means invest in blogging, holding community meetings, attending conferences to slowly spread the word to build a user base and to build credibility with the community. You also need to provide lots of user support, which means answering questions, contributing to forums, doing timely bug fixes and helping users on board to 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. Find target groups in the same domain and see if you can provide integrations for those projects, attend meetings and see if you can present. You know, if you have common problems, then you can work to resolve them so you can provide utility among the community and also generate some good feelings. So the last thing is that working in open source is very rewarding, even though it is tough and you need to put in legwork. It feels great when it happens. It's amazing to meet and work with people around the world, and it's incredibly satisfying to see amazing organizations use your product to develop new things. So what's next in our journey, both on the Intuit side as well as for the Argo project? So we've had a lot of success with Argo. We have a lot of quantifiable metrics in terms of the successes we've had in terms of increasing developer productivity, cost savings. So management at Intuit is really excited about expanding and increasing the commitment to open source. So we're hoping here as we move forward this year and then in the years to come that we'll have more innovations, more projects and even more resources that we can put into the open source community. We're also looking and hoping to graduate Argo here soon as part of the final step in the maturity process we've come a long way with Argo has some awesome adoption, has some really good projects within Argo and get to the last level of maturity within CNCF would be a good testament to all the hard work that all the engineers and contributors have put into this over the years. We're also looking at doing more cross-project and vendor collaboration and integrations here over the next year or so. We have a number of vendors that we're already working with within the community. There are more vendors who are looking at building solutions, products on top of or with with the Argo project. So we're really excited about having more alternatives for the community when they want to choose a commercial offering on this. We're also looking at using those Argo building blocks and integrating them with more and other open source projects. To make sure that we can build better solutions together, build better communities together and be a really good community player. So lastly, we just want to say thank you to all the amazing users and companies that are part of our community. It's been awesome to work with everyone. We've had a lot of good feedback and experiences working with all these companies. It's been a lot of beer, sweat and tears, but we've had a really good ride so far. Looking forward to getting to that tradition and go beyond that. So thanks, everyone, from these companies. If you are using Argo, thank you so much. If you're not, we'll change that shortly. Yeah, thank you to everyone who has contributed to the Argo projects over these years. We really appreciate the time and effort you've put into our projects. Yeah, so thank you, everyone, and thank you for attending this talk. Thanks, everyone. We'll see you in a live Q&A here shortly.