Co Source - Renamed Source Code Sharing Strategy

Co source

Protected Inner Source is a source code sharing strategy that defines an intermediate model between Open Source and Inner Source. The analogy used here is that C# Access Modifiers define a ‘Protected Internal Class’ as an intermediate between ‘Public Class’ and ‘Internal Class’. The purpose of which is to be more closed off between assemblies than ‘Public Class’, yet more open for reuse than ‘Internal Class’.

If you would like to read the previous article, please find it here: Open Source - Inner Source - Protected Inner Source

So what are source code sharing strategies anyway? Glad you asked! 👇

Source code sharing strategies refer to the various methods and practices used to distribute and collaborate on software code. These strategies determine who can access the code, how it can be modified, and the level of transparency involved. Understanding these strategies is crucial for organizations to effectively manage their software development processes and foster collaboration 🤝 & innovation 💡.

  1. Open Source: This strategy allows anyone to view, modify, and distribute the code. It promotes transparency and community collaboration. Popular examples include Linux and Apache. More about Open Source can be found here on Wikipedia.

  2. Inner Source: Inner Source applies Open Source practices within an organization. It enables teams to collaborate across departmental boundaries while keeping the code private to the organization. This approach enhances code quality and innovation by leveraging internal expertise. More about Inner Source can be found here on Wikipedia or here on GitHub.

  3. Closed Source: Also known as proprietary software, this strategy restricts access to the source code. Only authorized individuals or teams within the organization can view or modify the code. This approach is often used to protect intellectual property and maintain control over the software. How Closed Source compares to Open Source is described in further detail here on Wikipedia.

  4. 🚀 Co Source 🚀: The newly proposed hybrid strategy that allows sharing among certain trusted (or federated) organizations. These organizations operate independently but share a common 🤝 trust boundary 🤝, similar to how Protected Internal classes work in C#. This strategy promotes collaboration without specifically touching on security within the OSS space.

Each of these strategies has its own set of benefits and challenges, and the choice of strategy depends on the specific needs and goals of the organization.

For a more detailed overview of source code and its management, you can refer to the Wikipedia page on Source Code.

I received feedback on the name ‘Protected Inner Source’. It was mentioned that the label protected seemed to imply Open Source and Inner Source are not secure 🔒. This was and is not the intent!

In order to come up with a better name I had considered Federated Source, Trusted Source, Collaborative Source, Cooperative Source… and have decided on Co Source. The term ‘Co’ suggests both collaboration and cooperation, which aligns well with the idea of shared source code among trusted entities. It also keeps it clean and neat in daily use 😄

In the modern world of IT, many aspects of our industry are being changed by rapidly evolving (software) engineering innovations. The pace at which this happens has been impacted by Open Source ways of working, among others. What has become clear, is that these ways of working can have a drastic impact on the ability to innovate in any system.

In bridging organizational design (often business driven) and systems design (often technology driven), Co Source can help bring many benefits. Innovation can benefit especially much, as a core pillar behind the ability for organizations to change. It can drive organizations to change their culture in a way that makes them able to stay ahead of the curve. Competitive advantage driven by a culture of technological innovation.

Especially within organizations that do not have IT as their core business, it can be hard to adopt such a culture. Still, even for strictly business driven organizations it brings massive benefits. As Cloud has shown us in the past 10+ years, and as (Gen) AI keeps showing in the past 1-2 years, the impact is profound.

To those organizations that struggle to adopt these technology driven cultural changes, I would advise to consider enabling a culture around Open Source ways of working. Why? It enables individuals within those organizations with the freedom to demonstrate the benefits with concrete delivery of added value through innovation.

As more individuals in the organizations demonstrate added value and potentially massive impact on the bottom line, a platform of cultural growth is born.

Does that mean the Open Source ways of working need to be adopted specifically in that form? No, this is exactly why Inner Source was conceived to begin with.

Now to the point of Co Source. Organizations that have complex but trusted ecosystems such as government organizations, you can gain traction at an accelerated rate beyond what Inner Source enables within a single organization:

  • Enable a cultural shift towards one of technology innovation.
  • See demonstrated added value through delivery of early innovation scenarios.
  • Scale this process by embracing the success of this wave of success through technology innovation culture.

To reiterate, Protected Inner Source was not meant to imply Open Source is not secure. There are security challenges as with any strategy, and those can be managed in accordance with the relevant situation. Similarly, Co Source should still leverage best practices and proper design thinking to determine what works best when implementing this strategy.

As Co Source was introduced to introduce a new way of working within certain organizations or ecosystems, I will gladly refer to existing best practices in the OSS Security space. For instance, review the OpenSSF article on Strengthening Open Source Software: Best Practices for Enhanced Security.

As a specialist in #GovTech, I am primarily fueled by a vision of rapidly accelerating innovation in the public sector. Within the public sector, in any single nation like the United States or group of nations like the European Union, there are massive potential gains to be made by increased collaboration. Embracing the culture of technological innovation is at least one avenue towards to rapidly accelerate towards those potential gains.

How would this work? From any group of government organizations, setup collaboration through Co Source repositories and start demonstrating added value. Not just added value for the (government) organizations, but also to the citizens these organizations serve.

Even competing IT vendors working within the public sector can embrace the concept of Coopetition through Co Source. In doing so, we all improve the impact the public sector has on society as a whole.

Co Source has the potential to revolutionize collaborative development within an ecosystem of trusted organizations. By combining the innovative nature of Open Source with the organizational boundaries of Inner Source, Co Source offers a unique model that can be particularly beneficial for government organizations in the public sector. This approach allows these organizations to share resources efficiently and securely, fostering a culture of collaboration and innovation.

In a world where ecosystems are becoming increasingly prominent, Co Source enables organizations to build upon trusted relationships in source code sharing strategies. By establishing a culture of collaboration 🤝 and innovation 💡, organizations can drive technological advancements and achieve significant benefits. Embrace Co Source to unlock the full potential of collaborative development and propel your organization towards a future of innovation 🚀!

Related Content