At a time when collaboration and innovation are critical for an organization, an open-source development model is becoming ever more prominent. In this article, we delve into the world of open source and explore how it could revolutionize creative collaboration and push the boundaries of inclusive innovation within an organization and around the world.

Open-source communities have laid the foundation for some of the biggest technological leaps we have seen in numerous domains, especially in software. Some examples include Linux OS, Android OS, Kuberates, Gradle, and Apache HTTP server. Typically, these projects are hidden from the visibility of end users but provide immense value to software development and enhance the productivity of developers, which has led to continuous innovation in the services we rely on today. Open source is not limited to technology, however. Wikipedia is a prominent example of an open-source artifact serving as a modern-day encyclopedia. 

What Is Open Source?

An open-source community is a collaborative group of individuals who come together to develop, maintain, and improve artifacts that are easily accessible. In an open-source community, developers and contributors work together, sharing their skills, knowledge, and resources to create and distribute high-quality artifacts.  Most of the success of their projects can be attributed to the unique set of diverse talent that these projects attract, which opens up the opportunity to think outside the box. In this article, I will mostly focus on open-source within software.

Open Source Within the Context of an Organization

When we think of open source, we often envision a global network of contributors collaborating on a shared project. However, open source principles can also be applied within an organization's internal environment. Companies can cultivate an open development culture behind their firewalls, where only employees contribute, review, and merge pull requests, fostering collaboration and transparency among the organization's staff. 

Conversely, an organization may opt to release its code publicly while maintaining its role as the primary steward of the product. The Android Open Source Project (AOSP) serves as an excellent example of this approach. Led and primarily developed by Google, the project embraces open-source values by allowing public access to the Android source code. However, Google remains at the forefront of decision-making and actively guides the project's development.

The key point is that the openness and collaboration inherent in open source can permeate an organization's culture, regardless of the scale of the community involved. The fundamental principles of transparency, shared responsibility, and inclusive collaboration can be fostered within an internal development ecosystem and a public one. By embracing these principles, organizations can unlock the potential for innovation and collective intelligence among their employees.

Like most things, the decision to go in the open-source route depends on various factors. Thus, senior engineering leaders, in collaboration with legal and product, should analyze the nature of the project and decide which open-source model will fit their use case. There could be legitimate reasons to restrict access to artifacts, such as regulatory compliance or access to proprietary data. But the argument here is that not everything we work on needs to operate within those constraints, and it may be time to rethink the status quo.

The transition from a closed-source model to an open-source one has also enabled notable companies to expand their reach and forge deeper relationships within the developer community. By embracing open source, these companies have repositioned themselves as open-source-friendly and have gained the trust of developers. This trust has been instrumental in driving the adoption of their other products and fostering the growth of a vibrant ecosystem.

Why Would You Want to Have an Open-Source Community Within Your Organization?

Stronger Culture

Open communities inherently promote a culture of openness and transparency within an organization. In an open community, the needs and priorities of the community typically come before the individual. In that case, tools and processes are typically in place to facilitate a healthy community. For example, the code being submitted will go through rigorous review because the impact of that code is not limited to a specific product and team but also represents the values and brand of the community. Thus naturally, people will be inclined to share their code for review, request advice from experts early on, and adopt coding best practices such as simplicity, testing, and documentation. This also provides an opportunity to promote knowledge sharing among teams. As folks review code from a completely different team, they will start to understand the higher-level designs and implementations of the larger system, which will empower other members of the community to extend and customize existing open-source artifacts. Furthermore, within a common source control system, if a bug is introduced, it will likely affect multiple teams. As a result of debugging the bug, teams are exposed to code and tooling that was typically siloed. 

Inclusion and Sense of Ownership Among Employees

Open source projects often have diverse user bases, even within an organization, reflecting a wide range of backgrounds, cultures, and needs. Contributors are encouraged to understand and empathize with these users, driving the development of inclusive and user-centric solutions. This emphasis on inclusivity in design and user experience helps contributors feel that their contributions have a meaningful impact on the lives of diverse communities.

Moreover, open-source communities thrive on the principle of meritocracy. Contributions are evaluated based on their quality and impact rather than external factors. This allows contributors to be recognized and appreciated for their skills and dedication, irrespective of their professional background, age, or gender. The meritocratic nature of open source instills a sense of fairness and equal opportunity, creating an environment where everyone has the chance to succeed and contribute meaningfully. 

It is also important to be aware of some of the negative behaviors that may arise from open-source communities as well. The impact of this and how to prevent bad behaviors from spreading is discussed under the “Contributing guidelines” section below.

Better Infrastructure Resource Utilization

When a shared code repository is established, it often goes hand in hand with shared infrastructure through cloud computing. Consider a scenario where each team within an organization maintains its physical server pool for running jobs. This approach results in a significant amount of underutilized computing and storage space, incurring unnecessary expenses. Moreover, such fragmented practices can lead to lower code quality, as developers lack the incentive to optimize their code to align with community guidelines. In contrast, by implementing a shared infrastructure model, organizations can address these challenges effectively. With an organization-wide cloud computing infrastructure, the server jobs of each team can be dynamically scaled to match the actual demand, optimizing resource allocation and reducing costs. This ensures that compute and storage resources are utilized efficiently, minimizing wastage and resulting in substantial cost savings for the organization. Furthermore, the adoption of a shared infrastructure not only benefits the organization economically but also contributes to environmental sustainability. By consolidating compute and storage resources, power consumption is streamlined, reducing the carbon footprint associated with running multiple individual server pools.  For instance,  according to a case study by Google Cloud,  Etsy was able to save 50% in compute energy and improved compute costs by 42% as a result of moving to the cloud.  This cloud infrastructure, however, does not need to be from one of the big cloud vendors such as AWS, Azure, or GCP. An organization can still choose to procure its own physical servers (to be used for build and testing) that are managed centrally. That central organization could set up its own guidelines and automation to guarantee a balanced and reliable workload across teams.  

Therefore, we can see that cloud computing and open source development are symbiotic with each other, where open source can leverage the benefits (such as low overhead cost and scalability) afforded by cloud computing to engender communities of scale and open source development can accelerate an organization’s cloud migration readiness.

Note that the cloud infrastructure is meant for enhancing development at scale. Developers can still choose to compile and run their tests locally on their workstations and have the central infrastructure be used during code submission time. That hybrid practice is attractive because it lowers the load on the infrastructure, which translates to more cost savings. To implement this into practice, the central infrastructure can first build and test code paths that are the least expensive computationally. That way, errors that should have been caught by local testing are caught early on during the submission process, which can abort further processing of that session, freeing up infrastructure resources for other contributors.

How To Set-Up Open Source Communities

Here are some good practices on how to set up these communities based on first-hand experience in driving the thriving Android Jetpack community and also experiences with other communities that were not successful.

Clear Mission

A community thrives when it has a clearly defined mission that outlines its target audience and the significance of its work. This mission serves as a guiding principle, providing direction and purpose for the community and its participants. By establishing a clear mission, the community can cultivate empathy towards its intended beneficiaries and communicate the value it aims to deliver.

Let's take the example of the Android Jetpack community, which operates with a mission “To create components, tools, and guidance that makes it quick and easy to build great Android apps, including contributions from Google and the open-source community.” This mission statement reflects the community's commitment to providing resources that benefit both developers and users. By involving contributions from both Google and the wider open-source community, the Jetpack community embraces a collaborative approach that encourages diverse perspectives and expertise.

Seeking Out Expertise

To foster inclusivity, open-source communities should operate independently from organizational hierarchies. Participants should connect with one another based on their expertise and shared interests rather than their positions within the organization. This approach ensures that contributions are evaluated based on merit and encourages equal participation from all community members. As organizers of the community, we need to set up communication channels such as forums, documentation, and chat groups so that contributors get easy access to the expertise of other community members. In addition, we need to have an easy process to increase the expertise of the community and onboard them to become community leads in their areas.

In Android Jetpack, we have multiple forums, such as feature intake review groups and API counselors. These forums advise and consult on new features being added to the open-source artifact, guide API design processes, and create and enforce contribution guidelines. We also have chat groups and email aliases where community members can ask questions and get guidance. Participation in these forums is mostly voluntary and is built up of people with expertise in those areas. Jetpack also has an easy process for new contributors to get mentors and become members of these forums that lead the direction of the community. 

Contribution Guidelines

Clear contribution guidelines are essential for effective collaboration within an open-source community. These guidelines should be thoroughly documented and, ideally, enforced automatically. By setting transparent expectations for contributions, the community establishes a framework for consistent and meaningful engagement, enabling participants to understand how they can contribute effectively. One notable example is the "Principles" document in the Jetpack GitHub repository. This document outlines the guiding principles that Jetpack contributors are encouraged to follow. It covers important aspects such as stability, compatibility, and user-focused design. By adhering to these principles, contributors ensure that their work aligns with the overall vision and goals of the Jetpack community.

Another valuable resource is the "API Guidelines" document. This document focuses specifically on the guidelines for designing APIs within the Jetpack project. It provides comprehensive instructions on naming conventions, versioning, and documentation standards. Adhering to these guidelines ensures consistency and clarity in the APIs developed within the community, making it easier for other developers to understand and use the provided components and tools.

Finally, a non-technical guideline that focuses on the relationship among community members is needed. Community leaders and project managers need to collaborate to create a code of conduct artifact in order to create a safe space and clarify acceptable behaviors while being part of the community. For instance, AOSP has a clearly defined and accessible Code of Conduct for community members. Some key items from the COC document are: 

• Clear representation of acceptable behaviors (such as using inclusive language) and the ability for community members to report unacceptable behaviors.
• It is short and accessible, making it consumable for a large number of contributors.
• Well-defined scope to communicate what constitutes an Android contributor.

One of the primary challenges in open-source communities is the lack of face-to-face interaction. Online communication platforms, such as forums, mailing lists, and chat channels, may provide a sense of anonymity, which can embolden individuals to engage in disrespectful or hurtful behavior. This anonymity can contribute to the formation of toxic subcultures within communities, where some members belittle others' contributions, engage in personal attacks, or exhibit negative attitudes. It has been reported that of all the open source contributors, only 3% are women, and that could largely be a result of the sub-cultures above that metastasize without remedy. This leads to emotional distress, demoralization, and the alienation of victims, discouraging them from further participation and potentially driving away valuable contributors. Moreover,  it creates an unwelcoming and hostile environment, hindering the community's ability to attract and retain diverse talent. This can result in a lack of fresh perspectives and a narrower range of skills and experiences, ultimately limiting the community's potential for innovation and growth. As a result, it is the responsibility of community leaders to stay cognizant of unacceptable behaviors and address them proactively. 

These contribution guidelines from Jetpack and Android serve as excellent examples of how open-source projects can establish clear expectations for contributors. By documenting and sharing these guidelines, the community promotes transparency and provides a framework for effective and respectful collaboration. They offer a reference point for contributors to understand the standards and requirements set by the community, ensuring a consistent and high-quality codebase.

Furthermore, it is worth noting that these guidelines are well-documented and accessible to all contributors. They are openly available in the Jetpack repository, allowing anyone interested in contributing to familiarize themselves with the expectations and best practices established by the community. This accessibility reinforces the inclusive nature of the open-source community, welcoming contributions from a diverse range of individuals.

Use of Other Open Source Artifacts

Maximizing the use of other open-source modules is highly recommended for open-source projects. By relying on closed-source tools and modules, the community limits the number of people who can contribute to the project. Therefore, it is beneficial to explore various open-source options before resorting to closed-source solutions. This minimizes barriers to entry and fosters a broader community of contributors. For source code management, there are open-source resources such as GitHub or Gerrit that can coordinate collaborative code creation. Open-source tools such as Gradle (the build system used in Android Jetpack) can be leveraged to compile the code locally. This allows for any contributors to easily checkout the source code, make changes and build locally, and send their changes for review. 

Conclusion

Open-source communities have demonstrated their transformative power in driving collaboration, innovation, and inclusive development. Whether implemented on a global scale or within the confines of an organization, the principles of open source can have a major impact on the way we work and create. This is particularly important in the current world where teams are distributed across the globe, and a common purpose between those teams is needed. By embracing open source within an organization, companies can cultivate a stronger culture of collaboration,  transparency, simplicity, and learning through continuous feedback. Open communities encourage knowledge sharing, code review, and the adoption of best practices, leading to improved code quality and a deeper understanding of the overall system architecture. The inclusivity and meritocracy of open-source communities promote a sense of ownership and recognition among employees, fostering a positive work environment and driving meaningful contributions.