The first KCD (Kubernetes Community Day) Helsinki brought together a wide range of individuals. From university students to established experts that were there for the Kubernetes v1.0 release, from seasoned engineers to hobbyists no matter what your topic or level was, you could find a match in this group!

It is a privilege to get the opportunity to present in this context, and it is an honor to do it on the topic of how to become part of the community. Afterall, any community that fails to attract new members is doomed to die.

In our talk, we did not focus on this existential threat, but we have taken inspiration from the movie “Mufasa”, where it is very much visible. A group of animals choose to travel together, even though it may be a bit slow for some of them, because they are safer together. This is summarized in a song, of course:

“If you wanna go fast, go alone
there’s the road, off you go,
but if you wanna go far
we go together”

This is where we start our presentation. We wanted to make it clear that there is a choice. You don’t have to work with open source projects, but if you do, you need to set your expectations right. Sometimes things will move very slowly. There will be endless debates over tiny details, there will be absent maintainers, misunderstandings and delays. Luckily, you can improve things a lot by being prepared and proactive. For example, if you are aware of the different contexts that people may have in a project, you can provide enough information directly on first contact. This way you can avoid unnecessary delays from follow-up questions and answers, or even being ignored completely.

After this initial “expectations management”, we went on to look at why open source projects still may be beneficial. We focused on the kind of larger projects, like Cluster API and Metal3, where multiple parties are collaborating, and the projects are governed by a foundation, rather than an individual company or person. It may be challenging sometimes to collaborate, but it comes with benefits like a shared maintenance burden, no lock-in and perhaps a larger community to help drive development.

Finally, with a good understanding of why anyone would want to work in open source, we looked at how to actually get started in a project. This is something we are often required to do, as open source developers for Ericsson Software Technology, so we know what we are talking about here. It may feel counterintuitive, but it is almost always better to take it a bit slow. Don’t jump right in and try to achieve the main goal right away. You will almost certainly get stuck on trivial things just getting your development environment up or missing some guidelines. If you make it all the way and suggest a huge change as your first contribution to the project, the maintainers will scrutinize it down to the last character since they have no reason to trust you.

No, it is far better to forget about the goal first. Just approach the project as a user. Try it out. Look for contributor guides and perhaps a “good first issue” as warmup. Spend some time to get known in the community. Afterall, would you accept code from a stranger into your baby project?

We couldn’t leave the maintainers without some good advice either. So, we included a little part about what maintainers can do to make it easier for new contributors to join the project. For example, provide guides, good issues and be available for questions or mentoring.

So good, so far, we go together

❤️ Be polite – this is not customer support (and even there you should not be rude!)

🦾 Be prepared to work and don't be afraid to ask

• Check for known issues
• Test the latest version
• Gather data and try to fill out templates as best as you can

🏅Reproduction

• Can you explain the issue so that someone else can reproduce it?
• Someone from a different company?
• From the other side of the planet?

Together under 1 roof – foundations

So far in this post the Open-Source community was approached from a contributor's perspective who would like to contribute but there is nowhere to contribute to and there are no successful projects unless they have solid technical, legal and governance foundation and to have all those is a real challenge. Meeting this challenge is very hard without support. From this point onward, let’s discuss how projects go together to build an ecosystem that is worthy of receiving contributions.

As said before, we as an opensource community have to go together to achieve our goals.
The need for collaboration has been an undeniable necessity. Stakeholders of the opensource ecosystem have also recognized it is not enough to collaborate just on the technical level as a variety of projects have faced legal, governance, or other non-technical issues over the years. To tackle the non-technical challenges (also some of the technical ones) many non-profit organizations started serving as legal guardians of impactful opensource projects and by today most of the core projects that provide a base of our digital infrastructure are owned and maintained by such non-profit foundations.

These foundations like the Linux Foundation with its sister foundations like the CNCF (Cloud Native Computing Foundation) has grown into a huge, intertwined ecosystem that serves a protective umbrella over hundreds of well-known and widely utilized software projects that display different levels of maturity and complexity.

Foundations like the CNCF help projects across a laundry list of problem domains. Some domains are technical, such as curation and accreditation of projects, providing shared resources like computational resources or art resources like help with logo creation, or providing access to foundation branding. Foundations provide practical legal support serving as the intellectual property owner, providing guidelines for license usage but also having resources to tackle legal issues that might emerge during the lifecycle of the project.
Other than technical and legal support, foundations usually provide or accredit official training and certification as well as provide marketing and visibility for successful projects.

Maybe the most visible and well-known activities of the foundations are related to organizing and hosting both small, medium, and large-scale conferences, meetups, and other local and global networking events. Foundations help to facilitate better cooperation between individual contributors, users and maintainers as well as business to business, business to customer and business to government interactions for products and services that openly rely on opensource technologies. There is also one activity that is only doable with this foundation scale cooperation and that is advocacy on the legislative level. Foundations like the Linux foundation and CNCF were crucial in guiding and reviewing legislation like the European Union's new Cyber Resiliency Act (CRA) and later the foundation created training for stakeholders like developers and businesses explaining the practical application of the (CRA).

If you, the reader, would be facing the dilemma to make your opensource project join for example the CNCF, or you would be a product developing business looking for technologies to integrate into your stack but not sure if you should take foundation governed projects seriously there are a few numbers that you could look at in order to see what is the scale of an organization like the CNCF:

• 280,000+ contributor
• ~ 5000 maintainers
• 208 independent projects
• 733 member organizations
• Kubecon(s) in EU, US, Japan, China, India
• KCDs (Kubernetes community days), meetups all around the world
• Technical governing bodies: TOC, TAGs, SIGs

Huge numbers and great achievements, a truly global reach, and a lot of serious stakeholders from the industry.

Mature together – CNCF model

Even though the foundations have a lot of valuable functions and achievements, they are nothing without the projects they oversee. In the Open-Source Software community, the end goal is to provide reliable solutions for challenges faced by users/adopters. Organizations such as the CNCF took on the responsibility to guide projects to reach production grade quality and lead potential adopters to projects that fulfill their requirements. Thus, the CNCF maturity model and related guidelines were established.

CNCF divides projects into 3 maturity categories: sandbox, incubating, and graduated. Young projects usually start in the sandbox as they don’t have the level of maturity needed for the more mature categories. To get accepted as a sandbox project, maintainers must write an application with adequate reasoning whether the project fits the scope of the foundation, how the project would benefit the ecosystem, and the maintainers are required to explain the motivation behind joining the foundation. The Technical Oversight Committe (TOC) must vote whether to take the project in or not.

The next category is the incubating category, and it is much harder to get in, and it is considered the hardest filter according to the official documentation. Both current sandbox projects and external projects could submit an application to transition to incubating status but at this stage much more is required from a project compared to sandbox. After the application is submitted the project will be in a queue until a suitable reviewer is available and then the due diligence process is initiated that evaluates the project across multiple different domains of maturity and competency.

Projects applying for incubation or graduation are evaluated across six broad criteria sets such as:

• Governance and Maintainers
• Contributors and Community
• Engineering Principles
• Security
• Ecosystem
• Legal status

In case of incubation examples of aspects reviewed are:

• Governance is up to date with actual project activities, meetings, leadership, and approval processes.
• Clearly defined and discoverable process to submit issues or changes.
• Document and maintain a public roadmap
• Clearly defined and discoverable process to report security issues.
• TOC verification of adopters.

The incubation evaluation period could take more than a year, and both during and after the evaluation the project must be kept in shape that meets all the incubation criteria. For example, the community has to be so healthy that multiple adopter organizations have be willing to participate in adopter interviews conducted by the TOC. The continuously refreshed documentation of the evaluation criteria can be found here.
The final stage is the graduated stage; these projects have proven their long-term stability and usefulness in the ecosystem and meet all the criteria required from projects at a lower maturity level.

The set of requirements for a graduated projects can be summed up by saying that the project has to demonstrate the same qualities that an incubating project has but over a longer period even if the maintainers and the community members transition in and out of the project thus proving that the internal governance and technical guidelines and the value of the project are enough to maintain the project regardless of the loss of any individual adopter/maintainer or contributor.

As mentioned, the maturity guidelines evolve and have to evolve properly to maintain the relevance and the quality of the ecosystem. Projects have to continuously demonstrate that they deserve to be at their chosen maturity level and some projects indeed end up being archived as they lose momentum and become unmaintained.

One could ask why projects go through the hurdles of the various maturity evaluation processes. Partial reason is that passing the different evaluation milestones helps the maintainers keep the project on track by executing a pre-defined set of tasks to pass the evaluation. Another strong reason is that when projects pass from one stage to another the foundation provides more and more visibility and opportunities for the project to advertise itself for example in the form of help with organizing webinars, providing more opportunities on conferences and meetups. Incubating and graduated projects are included in best practice guidelines, SaaS architecture blueprints, training materials and different publications and resources prepared by the foundation. By gaining more visibility and notoriety, maintainers can attract adopters, sponsors, and contributors, thus increasing the health and longevity of the project.

Case study: Metal3

A good example of gradual improvement of maturity in the CNCF is the Meatl3 project that started as a cloud-native and almost CNCF native project that joined as a sandbox project after a year of development. Metal3 has spent a little bit more than 3 years in sandbox and then after applying to be evaluated it has spent 1 year in the queue waiting to get evaluated and during this period the maintainers were adjusting the application and improving the project to meet the changing requirements. After a year of waiting for the project evaluation, the TOC due diligence process took many months and at the time of writing this blogpost the project is waiting for the result of the TOC vote.

As a maintainer of Metal3 this period of transitioning between sandbox and incubation was an eye-opening experience. Most of the projects applying to incubation already have a strong technical foundation, and they are all used by adopters in commercial production environments. As it was mentioned above the projects are evaluated across six broad domains of competence/maturity and only 1 is related to the actual usability and technical quality of the project all the others cover governance, community, security etc., thus mainly non-technical topics.

Building together .... a community

The realization of the overwhelming impact of non-technical requirements leads to a need for contributors who would be willing to help any project fulfilling the non-technical requirements. It is a mutually beneficial way for new contributors who are not yet confident enough to do major changes on the codebase or any coding at all to investigate helping with activities such as:

• Join community meetings or help facilitate them
• Help with blog posts
• Write documentation
• Report bugs, issues, questions
• Disclose security issues responsibly, help build security processes
• Share on socials, maintain socials
• Help with the CI
• Join the chatgroups and mailing lists
• Comment on proposals

Never forget we get further if we go together!

If you'd like to hear more from us on this topic please check out our video.