Best Practices for Fostering Collaboration with the Open-Source Community in 2024
Tags: webdev, opensource, productivity, learning
Published: 2024-05-31 08:00:00

[_This post originally appeared on my blog_](https://forward.digital/blog/best-practices-for-fostering-collaboration-with-the-open-source-community)

Open-source software (OSS) has become an integral part of modern software development, with many organisations relying on open-source components to build their products.

However, using open-source software comes with its own set of challenges, such as security risks, licensing issues, and the need to contribute back to the community.

In this post, we delve into effective practices for engaging with and contributing to the open-source community, enhancing both your projects and the broader ecosystem.

## Open Source Program Office

An Open Source Program Office (OSPO) is a corporate entity that is responsible for managing an organisation’s open-source efforts. The OSPO is a “central nervous system” for open source within an organisation and provides governance, oversight, and support for all things related to open source ([Haddad, 2022](https://www.linuxfoundation.org/research/a-deep-dive-into-open-source-program-offices)). It trains staff, promotes efficient software development with open-source parts, guides open-sourcing projects, ensures legal compliance, and builds community engagement.

An OSPO helps bridge the gap between an organisation’s internal development and the external open-source community, helping to ensure that the organisation is a good steward of open-source software and can reap the benefits of open-source adoption, all the while minimising risks ([TODO Group, 2023](https://ospoglossary.todogroup.org/ospo-definition/)).

Six common characteristics of successful open source programs ([Walker, 2016](https://opensource.com/business/16/5/whats-open-source-program-office)) are:

- Value marketing and branding highly.
- Choose open-source communities that match your tech goals.
- Get good legal advice to balance risk and innovation.
- Your open-source efforts should support your product goals.
- Explain your support plans clearly to everyone involved.
- Hire someone passionate about open source to lead.

Uber, for example, was motivated to create its own OSPO because of the need to streamline support for various open-source initiatives. For instance, there was a significant demand for advice on incorporating open-source technology into external products from engineers. Key concerns included navigating compliance, licensing, and related legal matters. Additionally, there was a crucial need to offer engineers direction on how to release Uber’s own software as open source, whether by initiating new projects or contributing to existing ones ([Uber Case Study n.d.](https://todogroup.org/resources/case-studies/uber/)).

“It was natural and organic for Uber to create an open source program office since it allowed us to build our platform and scale the technology at unprecedented speed […] in essence, Uber loves open source because it’s essential to our success.” ([Hsieh, n.d.](https://todogroup.org/resources/case-studies/uber/)).

Since the OSPO is a relatively new concept, with Google opening one of the first OSPOs in 2004 ([Google, 2022](https://opensource.google/about)), the literature references mostly large corporate entities with the resources to create an OSPO. The Linux Foundation recommends a minimum of five employees to start a successful OSPO ([Haddad, 2022](https://www.linuxfoundation.org/research/a-deep-dive-into-open-source-program-offices)). Therefore, an OSPO is not best suited for smaller organisations that cannot afford to dedicate the resources to an OSPO.

## Open Sourcing Previously Proprietary Software

Open-sourcing previously proprietary software is the process of releasing software to the open-source community for free use and modification. This process can be beneficial for organisations; it allows for increased innovation, collaboration, and community engagement and can lead to the development of features that are beneficial to the organisation, as well as the resolution of issues that impact the organisation’s operations.

There are a series of examples of organisations open-sourcing previously proprietary software. Some of the most notable examples include:

**Microsoft Open-sourcing .NET** By open-sourcing .NET, Microsoft allowed for a single, collaborative codebase across platforms rather than separate implementations. Ultimately, open development allows more community engagement to provide feedback and contributions, making the stack better for all ([Landwerth, 2014](https://devblogs.microsoft.com/dotnet/net-core-is-open-source/)).

**Microsoft Open-sourcing Powershell** Microsoft open-sourced PowerShell to make it more widely available and helpful for system administrators and developers who work with multiple operating systems. By making it open source and available cross-platform, more people can use PowerShell to automate tasks and manage their diverse computing environments that include different OSes ([Foley, 2016](https://www.zdnet.com/article/microsoft-open-sources-powershell-brings-it-to-linux-and-mac-os-x/)).

**NVIDIA Open-sourcing PhysX** NVIDIA open-sourced PhysX because physics simulation has “dovetails” with AI, robotics, and computer vision. NVIDIA considered physics simulation “foundational for so many things” and open-sourcing it would allow it to be developed and applied more widely than NVIDIA could do alone ([Lebaredian, 2018](https://blogs.nvidia.com/blog/physx-high-fidelity-open-source/)).

**Microsoft Open-sourcing Live Writer** Microsoft open-sourced Live Writer to allow the community to continue to develop and improve it, as Microsoft no longer had the resources to maintain it ([ARS STAFF, 2015](https://arstechnica.com/information-technology/2015/12/microsoft-open-sources-live-writer-beloved-but-abandoned-blogging-tool/)).

The primary motivation for open-sourcing previously proprietary software is to allow for increased community engagement, feedback, and contributions, making the software better for all.

However, open-sourcing previously proprietary software does have some technical considerations. For example, the software must be properly documented, the code must be clean and well-structured, and the software must be properly licensed. We saw from the interviews that these technical considerations are usually a deal-breaker and the reason why organisations do not open-source their software.

## Hiring

To reduce the risk of using OSS, organisations should hire internal staff to manage OSS. Develop in-house proficiency and aim to reduce reliance on external service providers by cultivating organisational expertise to oversee projects. This approach will enable quicker deployment of upgrades and enhancements ([Team Srijan, 2010](https://materialplus.srijan.net/resources/blog/migrating-open-source-survival-guide-smes)).

Smaller organisations might not necessarily hire new personnel but rather delegate the responsibility to an existing staff member who is recognised as a subject-matter expert within the specific area (Interviewee 8, 2024). This approach is viable because, as noted, “In general, open source developers are experienced users of the software they write. They are intimately familiar with the features they need, and what the correct and desirable behavior is” ([Mockus et al., 2000](https://dl.acm.org/doi/10.1145/337180.337209)). This innate understanding significantly mitigates one of the primary challenges in large software projects: the lack of domain knowledge. Consequently, smaller organisations can effectively rely on their in-house experts, capitalising on their comprehensive knowledge and experience.

Hiring is a significant investment, and it is not always feasible for smaller organisations to hire new personnel to manage OSS.

## Culture

Open source has always been deeply rooted in culture, originating as a grassroots movement advocating for software freedom. Culture encompasses a broad spectrum, and individuals and organisations get involved in open source for various reasons.

When inquiring about the cultural drivers behind companies’ engagement in open source, innovation emerged as the leading motivation, with 84% of respondents to Fintech Open Source Foundation State of Open Source Survey affirming it as a critical factor ([Ellison et al., 2021](https://www.finos.org/reports/2021-state-of-open-source-in-financial-services)).

Uber instituted internal standards for governing and incentivising contributing upstream and back to the community to encourage ongoing, regular involvement in open-source projects. Contributing back to the open-source community is one of the best ways to help ensure open-source project sustainability ([Uber Case Study n.d.](https://todogroup.org/resources/case-studies/uber/)).

A big part of culture is fostering an environment where developers feel comfortable taking an unconventional route to solve a problem ([Autodesk Case Study n.d.](https://todogroup.org/resources/case-studies/autodesk/)), and where they are encouraged to share code and collaborate with others ([Abernathy, n.d.](https://todogroup.org/resources/case-studies/meta/)).

An organisation’s culture is a significant factor in the adoption of open-source software, one that is quite hard to quantify and measure. There was very little mention of culture in the best practices we reviewed, and from our interviews, we found that there isn’t an “open-source” culture but rather a more collaborative and innovative culture that is conducive to using open-source software.

## Contributions

Active engagement in the open-source community offers substantial rewards. When you contribute to the projects your organisation utilises, you’re boosting its reputation and playing a significant role in steering the software’s development path. Such proactive participation can lead to the development of features that are beneficial to your organisation, as well as the resolution of issues that impact your operations.

Contributing to the open-source ecosystem extends beyond just coding. Offering documentation, identifying bugs, and aiding in translations represent other crucial ways to contribute. Through these contributions, you help cultivate a mutually beneficial relationship with the community ([Yborra, 2024](https://vaultinum.com/blog/managing-open-source-software-integration-in-software-development#best-practices-for-managing-open-source-software-integration)).

Contributing also helps keep the open-source component active and maintained. In recent years, a notable challenge has been the shortage of contributions or ongoing maintenance for projects, affecting even highly utilised packages like gorilla/mux, which have struggled to secure maintainers and consequently, had to archive their projects ([Norblin, 2023](https://www.scaleway.com/en/blog/foss-giving-back/)).

Another way to contribute is through financial support. A recent survey by DigitalOcean found that only 20% of respondents had been paid for their contributions to open source, while 53% agreed or strongly agreed that individuals should be compensated for their work ([DigitalOcean, 2022](https://anchor.digitalocean.com/rs/113-DTN-266/images/DigitalOcean-Currents_June-2022.pdf)). This suggests that there is room for improvement in financial support for open-source contributors ([Tandochain, 2023](https://tandochain.medium.com/the-importance-of-financial-support-for-open-source-software-bb486f32b145)).

More work is being done to support financial contributions to open source; notable examples include GitHub Sponsors and Open Source Collective, both offering platforms for financial support of open-source projects ([Open Source Collective 2024](https://www.oscollective.org/); [Explore GitHub Sponsors 2024](https://github.com/sponsors/explore)).

Contributing to the open-source community is a best practice for managing the security risks associated with OSS. Most of the literature we reviewed mentioned contributing to the open-source community as a best practice. However, from our interviews, very few organisations contribute to the open-source community, and those that do do so in a limited capacity.

## Hosting Events

Hosting events is a great way to engage with the open-source community. Events can be an excellent way to engage with the open-source community, and they can take many forms, from hackathons to conferences to meet-ups.

[Schumacher, 2022](https://www.youtube.com/watch?v=6UMCe5o0KBw), went as far as to say that corporate organisations looking to lead in open source should host events, as they are a great way to engage with the community and build relationships.

However, our interviews found that hosting events is not widely used in practice and that the best practices landscape does not reflect the real-world use of hosting events. Companies do send their employees to events, but larger organisations typically host events, as smaller organisations do not have the resources to host events.


## Conclusion

In conclusion, fostering collaboration with the open-source community is essential for organisations that rely on open-source software. By engaging with the community, contributing back to the community, and hosting events, organisations can enhance their projects and the broader ecosystem.

However, there are challenges to fostering collaboration with the open-source community, such as the need to hire internal staff to manage OSS, the technical considerations of open-sourcing previously proprietary software, and the cultural challenges of adopting open-source software.

Despite these challenges, the benefits of fostering collaboration with the open-source community are significant. By following best practices for engaging with and contributing to the open-source community, organisations can enhance their projects and the broader ecosystem, ultimately leading to better software for all.