Community over code: building successful open source projects

Speaker 1: So hello, everyone. Thanks for joining this online presentation. As the slide suggests, today, we are going to talk about the community over code principle, and in particular, how this principle can help you to build successful open source projects. A bit about myself. So as it was said right now, I'm working at DevRel.

Speaker 1: I'm running DevRel at GridGain. And, also, I spent most of my time working with Apache Software communities and with Apache Net community in particular. Before that, before running this DevRel team, I was wearing many hats. I was working in engineering. I was running product management.

Speaker 1: I spent some of my time even in sales and technical support. But still, my roots belong to the technology evangelism and developer relations. Because my professional career started at Sun Microsystems where I was working with a technology evangelism group. I was building local Sun communities where I helped application developers to adopt technologies such as Java, NetBeans, and Solaris. And after Sun was acquired by Oracle, a little bit later, joined Oracle Java engineering team.

Speaker 1: I was developing Java libraries and frameworks. And still, during my spare time, I was building nice demos. I was giving talks on Java technologists trying to explain the Java community members how to use this technology better. So what we are going to learn throughout the next eighteen minutes? First thing first, we have to start with the community or core principle.

Speaker 1: In fact, that's the north star or the motto of the Apache Software Foundation. So we'll spend, like, like, two or three minutes. I will introduce you to the Apache Software Foundation, but, hopefully, most of you are aware of this open source communities. And then we will take and break down this community over code principle by taking Apache Ignite as one of the projects of the foundation, and they will discover how this community over code principle helped Ignite to kind of grow from a small open source project to a lively and healthy community. Alright.

Speaker 1: Community over code. Or as always, sometimes we say community is bigger than code. What it means? If you Google for this term, you might end up being on many website pages of the Apache for file foundation. I would say that there is no any precise definition, but this one, I like the most.

Speaker 1: Most successful long lived projects value a broad and collaborative community over the details of the code itself. What does it mean? Let's take a simple example. You are you you you started your startup company, and you want to build, that open source project, and you want to build a community around this project. So you hired a couple of talented and smart engineers.

Speaker 1: And, basically, you open sourced your technology. You are building the technology together. But then suddenly, you see that your community does not grow. Yes. Your smart people can write code quickly.

Speaker 1: They can do a lot of releases, but the community does not excel. And then you find out that your engineers whom you hired are not collaborative. They don't want, you know, to collaborate. They don't want to help others to grow. They don't want to see anybody else in this community.

Speaker 1: And then you have a trade off. Probably, you would kind of educate them. You would change their minds, or you can let them go. Or if the code is of the most of the biggest value for you, then you can leave these guys, but then forget about the community. You might still have a good open source project, but that will not be the project that is driven by a broader community.

Speaker 1: And the idea of the code or community of the code principle is that even if you have smart and talented engineers in your company, but if those engineers are not ready to collaborate and become a part of a broader community, then it's better not to kind of work with such engineers or just better not to build the community with such people. So and this community over code principle is used by more than 340 top level projects of the Apache Software Foundation. So right now, we have more than 7,700 commuters who drive and build these projects. And, also, at this Apache. For our foundation, we decided to do a simple calculation.

Speaker 1: We estimated that the total code value of all these open source project exceeds $20,000,000,000. So if to give you an example, most likely, software company uses Apache Software Foundation technologies. From the space station to big banks to retail companies, let's do a simple exercise. Go and talk to your application developers of your companies and check if they use any Apache software technology. Most likely, they will.

Speaker 1: And Apache Ignite is one of the examples or one of the projects of the foundation. And we will take this project to break down the code over principle in bit more details. So I I belong to this community. I spent a lot of my time working with this community. I'm a committer and project management committee member.

Speaker 1: And this project basically is a distributed memory database that can keep your data across a cluster of machines, and then you can process it really quick. This project was donated by GridGain, the company I'm working for in 2015. And right now, we have more than 300,000 downloads per month, and the project is among the top five projects of the foundation ranked by the user released and their released activity. Alright. So now let's see.

Speaker 1: That was year 2015, and we at the GridGain decided to donate Ignite to the open source community. And our first stage was so called newborn stage, and the goal of this stage is to build that core community. Luckily, at the Apache Software Foundation, we have our Apache incubator. That's the special place where every open source project arrives if it wants to become a top level project over the foundation. So you will not be able, you know, just to go ahead and claim that you became a top level project of the foundation unless you graduate from this incubator.

Speaker 1: And if you want to graduate, your primary graduation criteria will not be related to any code. Nobody will be taking care of your code. If you are already in the incubator, most likely, the foundation discovered that there is a real value in your project, and it makes sense to make your project a resident of the foundation. And your primary exit criteria would be, is your community ready to become a top level project? And to to to to become ready for to become ready for the graduation, you have to focus on several tasks.

Speaker 1: First of all, diversity. What it means? When we were donating Ignite to the foundation for the very first weeks or even month, all the contributors were affiliated with GridGain, and that's not good. If you want to graduate, you have to have applicable contributors from other companies. They might be independent or they might should not be affiliated with CreepGain.

Speaker 1: That's the very first requirement. That's what we call community. Second, longevity. There there has to be a core group of the contributors who can continue maintaining and driving your project even if a big fraction of people leaves your project. It can happen.

Speaker 1: Sometimes contributors come, community contributors go, but you have to have the core com group that can drive your project forward, that can fix security issues, and that can produce releases. Self governance, what it means. In particular, in the Apache Software Foundation, I do believe that in other foundations, we don't have any roles or titles for managers. There are no any project managers or product managers. Nobody is coming to the contributors and saying, guys, that's our road map.

Speaker 1: Now please take your tasks and go ahead develop. Let's work on the next version of the release. It doesn't work this way in the in open source. Your code contributors have to learn how to govern their project without any management titles. So the same code contributors who are committing APIs or changes, they will be producing releases.

Speaker 1: They will be together deciding on what would be the the next road map, what would be the next features of your project. So know any management, know any kind of governments in that classical enterprise way. And finally, probably the most important one is open collaboration. When we work for enterprise companies, even like at GreenGain, it's absolutely perfect, you know, to go on a call, phone call, or just to Slack with to chat and Slack with someone and quickly make a decision about some improvement. But that's not the way how things work in open source.

Speaker 1: If, let's say, you want your your engineers who belong to this community want to do some significant change in the project, then, yes, they can discuss everything in the kitchen. But then before doing any changes, they have to start a discussion. Mail discussion or mailing lists so that the other community members can get involved in this discussion. So why does it matter? Several things.

Speaker 1: First of all, all the contributors can live in across different continents, different time zones. Not everybody can speak English fluently. That's why all the major decisions are not taken on phone calls. And, also, sometimes people need to a lot of contributors are volunteers. They cannot, like, check your email today and the report respond instantaneously.

Speaker 1: Sometimes they need to take more time for that. That's why mailing lists are the primary communication channel on the community because you want to get as many people as possible to be involved. So what it means for your company when you are entering this newborn stage? And here is we're talking about your company that decided to donate a project to a foundation like Apache. So first of all, you're going to undertake changes in your engineering organization.

Speaker 1: It's inevitable. But, also, the the biggest and most profound change is the culture shift in your company. Let me explain this in more details. When it comes to the changes in the engineers engineering team, there will be, you know, some, you know, functional changes. Like, you have to follow you have to use the toolset of the Apache Software Foundation, or you have to follow some release practices, etcetera.

Speaker 1: But the biggest changes are public communication. That's what I already mentioned. Yes. Your engineers are encouraged still to communicate daily with each other if they work for the same company. But if there is any significant change that has to be done with this open source project, that has to be discussed on mailing list so that the rest of the community can be involved.

Speaker 1: And, also, you, as, let's say, management of the company, have to encourage and also allocate time for your engineers to mentor other external contributors. External contributors will be sending pull requests. They will be asking questions, and that takes time to review everything. And if you're not prioritizing this for your engineering organization, guess what? Your community development community is not going to grow because nobody supports your external contributors.

Speaker 1: As for the company wide cultural shift, remember, the the one thing that you need to remember really quick is that once you donate the project to the foundation, that's no longer your IP. It no longer belongs to you. That's why fight the temptation to manage the community and the project evolution. If you're a product manager, project manager, or CTO, don't come to the community and tell even your engineers in a kind of what to do, what needs to be done. Don't try to enforce any road maps.

Speaker 1: Don't try to enforce any release life cycles. Yes. You can join the discussion. You can propose changes. You can propose road maps, but you are not allowed to manage.

Speaker 1: You have to earn your merit. And when we are saying about the merit and the Apache Software Foundation, you have to contribute. As long as you contribute to the community, to the success of your project, then your voice will matter all the time, and other contributors will be listening to you. But titles don't work in the community. Alright.

Speaker 1: So what we learned during this stage? First of all, the cultural shift takes more time. Ignite graduated successfully from the incubator, but still it took us a longer time to fight the old habits, like, related to the old management practices and so on and so forth. But remember this. We took community at the first priority, and that helped us gradually to become stronger and bigger.

Speaker 1: And finally, we arrived in the toddler stage. So how do I define this stage? So here is you already have your project became popular, and you are getting a lot of the users who can download your project and start using for their applications. Alright? And the problem here is that the number of users will dwarf the number of your community members.

Speaker 1: And those users, they want to use your project. So they will be asking for details, like how to install it, how to optimize it, how to troubleshoot it. They will be hitting some unique problems, and they will be sending questions to their community. And guess what? Your small group of code contributors will not be able to handle everything.

Speaker 1: Right? They came to the community for fun. They want to develop your code technology. They are developers. But users are coming and asking for a professionally written documentation.

Speaker 1: They are asking for detailed responses on their questions, and your developers are not able to handle everything. And what happens if if your community treats code as the biggest priority over the community? Then what happens with many projects is that you end up having poor documentation because developers don't want to write it or developers are reluctant to respond on the user list. That's why if you want to truly focus on the community over core principle, again, what can you do with your community? You have two problems.

Speaker 1: The first one is your documentation. And documentation, ideally, even for open source projects, have to be treated as your level number one technical support. If people Google for any question, they have they ideally should arrive on the technical documentation. If they cannot find any details on the technical documentation, then they can send the question to your mailing list, and they have to find the well written response. So what we had what did we do with Apache Ignite?

Speaker 1: Because we really hit this problem really hard. So we focused on the community, and we decided to expand and diversify our community. We brought in professional technical writers to Ignite. Also, those technical writers started writing and became responsible for the technical documentation. In parallel, we kept educating the rest of the community on the value of the the documentation.

Speaker 1: We we showed Google Analytics metrics. We confirmed that the number of questions reduced to the user list, etcetera. And guess what? Over the time, development community saw the value, And several developers, they came, raised their heads saying that, guys, I want to kind of create this documentation page because someone asked for it. Please, could you review it?

Speaker 1: And that also helps to build better bonds between your core contributors and technical writers. That's exceptional. But here is don't forget about one thing. You have to treat and recognize technical writers as you would treat and recognize your code contributors. With at Apache Software Foundation, it's simple.

Speaker 1: Our technical writers, they also can climb up this growth ladder. Just your contributor, then you can become a committer, then you can become a member of project management committee. At Ignite in Ignite, we have a technical writer who is already a committer. And the same recipe I would suggest to I use for your kind of for your user support. Most likely, if you are the company that donated this project, you have enterprise support.

Speaker 1: So negotiate and allocate part of your customer support team time for support of your user open source users. It's it's it's it's really easy. And, also, once you once you start in doing that, your open source users will see that this project is truly unique. You're writing nice code. The project is valuable.

Speaker 1: Your documentation is professionally written. And, also, they find professional responses on the user lists, and it will all works. And then some of the code developers, they also will join those user release discussions because they also want to be helpful. They will follow those professional customer customer support team guys. It doesn't mean that you have to do this all the times.

Speaker 1: As soon as your project grows and becomes, let's say, as big as Java, Kubernetes, or, let's say, Docker, most likely, you no longer need to invest the time of your customer support team in the support of your users because your your your community became user base became so big enough that the old users can support the newcomers. But, anyway, in Ignite and Ignite, we still have to do this because Ignite is not as big as, let's say, Kafka or Java. And, also, recognize everybody who spends time working with your users. For instance, when it comes to code contribution and technical documentation contribution, it's so easy. You can become a committer.

Speaker 1: You can become a project management committee. When it comes to their presentations, support, etcetera, we at GridGain internally have leaderboards where we value every contribution, let it be a blog post, let it be support of their users on the user list, etcetera, etcetera. K? So what's the primary outcome of this stage? Professionals should write documentation and work with the users, especially at this stage while your project is getting momentum and getting the very first users.

Speaker 1: And the final stage, ten years. So your your project already stands solid on the ground. And here is what might happen. Another big enterprise company might become interested in your project, like IBM, Google, Salesforce. They want to come and contribute to it because and and that can lead to community split if you're not working on this.

Speaker 1: So what are the distinct problems of this stage? All the enterprise companies, however you say it, they pre they have set their business goals in mind. They're not just contributing to the open source for free. Also, many enterprise companies, new enterprise companies, they will bring in a lot of engineers. And those engineers have to be educated on your community principles, on your values.

Speaker 1: And what's the most probably threatening for your company that was the with the community since the inception is that another vendor can start contributing features that you're already selling in your enterprise offerings. And here is, again, stick to this community over code principle, but also you can expand it, saying that community is bigger than code plus business. What it means for your company, which is with the community since with the since the inception, you have to celebrate this event when a big another enterprise vendor comes to the community and decides to invest by bringing in new engineers. Because that's the growth. That's a significant growth of your project.

Speaker 1: It means that you achieved some significant milestone. It's not a big deal that some of your enterprise features might appear in the open source. Just move on, evolve your business models, create new features. You have to move on together with your And when it comes to the to how can you avoid fractions, we just go ahead and talk to other vendors. It's just, you know, a universe recipe.

Speaker 1: If, let's say, you see that there are some conflict of interest, find like minded people on the other side of the bridge. Go and talk to the people who work for that new vendor company. Align on your plans. Align on your resources. Do and drive this project together.

Speaker 1: So we're actually at this stage right now in Ignite, and there are two major vendors who are contributing to Ignite. And we are trying to build these bridges. Sometimes it works, but still we keep running this conversation. And it works really well because Ignite is growing more rapidly because too many com many more companies are building it. Alright.

Speaker 1: Summary. Wrapping up. Community over code. If you truly want if if your goal is just to build an open source project, probably you don't need to have any community. You just can hire some talented and smart people who can release your project quickly.

Speaker 1: But if the community matters to you, then community goals and needs has to prevail. Build a healthy community, and it will pay you off in the long term. And don't worry about the code. Code will not suffer. Your talented and involved people will figure out how to build a high quality software.

Speaker 1: Yes. It might take more time because they have to come to a consensus or the mailing list. You don't you cannot release new product versions frequently, but it it's all worthwhile. Right? So thanks a lot.