Blogs

At a recent session of OpenChain & Friends 2026, the standard slide deck was replaced by a whiteboard and a candid, community-driven discussion. The goal? To map out how an Open Source Program Office (OSPO) moves from manual chaos to automated efficiency.

1. The Foundation: Policy and Configuration

The group reached a rapid consensus: Policy is the “North Star.” Every automation effort must stem from a clear policy. However, participants emphasized that automation isn’t a “set it and forget it” tool. It requires proper configuration to yield meaningful results; otherwise, you are simply automating the generation of “noise.”

2. The Carrot vs. The Stick

The discussion split OSPO responsibilities into two clear tracks:

• The Carrot (Value/Contribution): Automation here focuses on lowering the barrier for Open Source and InnerSource contributions. By streamlining the “give back” process, companies unlock developer productivity and innovation.

• The Stick (Compliance/Cost): This is the defensive play. Key components identified for automation include maintaining a List of Approved FOSS, tracking all components, and utilizing both static and dynamic detection for license and security (best effort) compliance.

3. Solving the Supplier & Legal Bottleneck

A major takeaway involved the supply chain. Supplier compliance is non-negotiable, but how do we get them there?

• Peer-to-Peer Convincing: If a supplier is stuck using outdated methods (like manual snippet scanning), the most effective solution isn’t a stern email—it’s a connection. Introducing them to another OSPO with a successful automated setup provides the social proof needed to change their workflow.

• External Legal Intelligence: For those without a dedicated legal team, the room recommended leveraging industry-standard resources like the OSADL License Checklists or the ScanCode database to verify license requirements.

4. The Power of Upstream and Community

The final, and perhaps most vital, point was about the human element behind the automation.

• Fix it Upstream: When you find a bug or a compliance issue, fix it in the actual project. Upstreaming doesn’t just help the community; it saves your team the effort of maintaining a private fork forever.

• Talk to the Experts: If you are stuck, don’t hire a consultant who doesn’t understand the “flow.” Reach out to the community. The best advice comes from those who are actively part of the ecosystem and understand the nuances of the projects you use.

At the Open Chain and Friends event this March, one session stood out for its immediate practical value. Divided into two parts, the presentation moved from the “Why” of community curation to the “How” of technical implementation.

Following the Chatham House Rule, here is a simplified breakdown of the most practical session of the day.

Part 1: The Community Approach (OSSelot)

The first half of the session addressed a common headache: every company spends hours scanning the same open-source packages (like curl or bash) independently. This is a massive waste of resources.

The solution presented is OSSelot—a public curation database. Instead of starting from scratch, you can download pre-cleared compliance data.

• What you get: Curated SPDX reports, license texts, and copyright notices that have already been reviewed by experts.

• The Goal: To drastically reduce the time needed to clear a software package by reusing existing work.

Part 2: Putting it into Practice (FOSSology)

The second half, led by a deep dive into FOSSology, showed exactly how to automate this workflow. The beauty of this approach is in how it handles version updates.

The 3-Step Workflow:

1. Baseline Upload: You upload the “official” version of a package from OSSelot into FOSSology (often via a simple API call or URL upload).

2. Import Curated Data: Since the OSSelot data is already “cleared,” FOSSology absorbs this information instantly.

3. The “Delta” Scan: When you need to check a new version of that software, you run a scan and tell FOSSology to reuse the results from the OSSelot baseline.

Why this is a game-changer: FOSSology will automatically match the files that haven’t changed. You only have to manually review the new or modified files.

Final Thoughts

This was very practical and most interesting session for me at that day. It transformed the daunting task of license compliance into a manageable, collaborative process. By using community-curated data and the “Reuse” features of FOSSology, we can stop reinventing the wheel and focus only on what has actually changed in our code.

It’s a perfect example of how sharing creates value for everyone in the open-source ecosystem.

The Problem: From “Bricks” to “Concrete Walls”

Traditionally, Open Source was built like a brick house: humans shared small patches of code, talked to each other, and built a community.

Today, we are facing the “Concrete Wall Drop.” AI can generate entire modules in seconds. Instead of humans collaborating, we have AI agents “dropping” massive amounts of code into projects. This is what experts call AI Slop—code that looks professional and has great documentation, but is often messy, redundant, or plain wrong inside.

The Reviewer’s Nightmare

The biggest issue is that writing code is now infinite, but checking it is not. * The Bottleneck: AI can create 1,000 lines of code instantly, but a human still needs hours to make sure it doesn’t have security holes.

• The Shift: The hard work has moved from the writer to the reviewer. Maintainers are getting exhausted trying to spot “hallucinations” hidden behind neat-looking AI formatting.

Why the System is Shaking

Open Source used to work because of visibility. You used a tool, talked to the creator, and maybe donated or hired them.

Now, AI agents act as middlemen. A user asks an AI for an app, the AI grabs the code, and the user never even sees the human who actually maintains it. This makes the developer’s work invisible. If the people building the foundations of our software aren’t seen or supported, they might just stop building.

What’s Next?

We are moving into an “AI-native” world. To survive the Slopageddon, the community needs to find new ways to:

1. Spot the “Slop”: Filter out low-quality AI code automatically.

2. Protect Humans: Make sure the people behind the code are still visible and supported.

3. Redefine Trust: We can’t trust code just because it “looks” right anymore.

The bottom line: AI can write code, but it can’t take responsibility for it. Keeping humans in the loop is the only way to save Open Source.

In the realm of cybersecurity, the theory of supply chain security often appears clean and straightforward. The reality is different. It’s a complex, multi-faceted challenge riddled with common yet dangerous mistakes that persist across organizations. This vital session, presented by Daniel Mihajlov from Robert Bosch GmbH, offered a practical look at the danger of neglecting software supply chain security. Understanding the software supply chain security regulations is no easy task. It involves a multitude of stakeholders, from developers and legal teams to incident response units, authorities, and third-party companies. This complexity demands a unified, comprehensive strategy, moving beyond mere reactive measures to embrace proactive security.

Mihajlov highlighted a critical issue: “Checkbox compliance.” This occurs when individual departments complete their own security checklists without anyone taking a holistic view of the entire system. While all the paperwork might be perfect, this siloed approach inevitably leaves some weak points, creating a false sense of security. The problem isn’t the compliance checks themselves, but how they’re conducted – often prioritizing documentation over actual security posture. This leaves organizations vulnerable despite their best efforts.

Another compelling example of a common vulnerability is the “ghost ship” – widely used applications relying on old, unmaintained open-source libraries for critical functions. Imagine a scenario where the original developer has moved on, no one monitors the project, and crucial security updates or patches are simply not happening. If a publicly known critical vulnerability emerges in such a component, the entire application sails into dangerous waters. A dependency without an active maintainer is, undeniably, one of the biggest problems in today’s software landscape.

The session reinforced these points with numerous use cases and real-world attack examples, mentioning also how the artificial intelligence based solutions used today to do more sophisticated attacks against companies. Lesson learned: even if your internal systems are robustly secure, your entire security posture is only as strong as your weakest link – including your suppliers’ systems. If you share data with a vendor whose systems are compromised, your data is also at risk.

At a recent gathering of open-source compliance and education experts, a transformative approach to corporate learning was presented: Eclipse OSILK (Open Source & InnerSource Learning Kit). The presenter highlighted how the industry is moving away from static, hard-to-maintain training decks and toward a developer-centric “as-code” model.

The Problem: The “Maintenance Trap”

Organizations today face a significant challenge in scaling open-source literacy. While training materials exist, they often suffer from:

• Poor Reusability: Rigid formats (like PDFs or complex PowerPoints) make it difficult to extract and repurpose content.

• Customization Barriers: It is hard to adapt generic open-source training to an organization’s specific internal policies.

• Stagnation: Once created, these materials are difficult to maintain, quickly becoming outdated as technologies and licenses evolve.

The Solution: Eclipse OSILK

The core philosophy of the session was simple: Treat training material like software source code. By using AsciiDoc—a lightweight markup language—training content becomes text-based, modular, and version-controlled. This “Training-as-Code” approach offers several key advantages:

• Collaborative by Nature: Using tools like Git, multiple contributors can track changes, manage releases, and accept community contributions via pull requests.

• Single Source, Multiple Outputs: A single text file can be rendered into various formats (slides, web pages, or handbooks) using tools like Antora or Pandoc.

• Modular Content: Content is broken down into small, reusable snippets. As shown in the “Modular Content Structure” diagram, specific modules (e.g., JS, PHP, or C# specifics) can be pulled into different “Courses” as needed.

• Forkable: Just like software, an organization can “fork” the OSILK base materials and add their own internal compliance layers without breaking the link to the original source.

Roadmap and Real-World Use

The initiative, currently in the Eclipse Incubation phase, is already seeing adoption by major players like Michelin and various engineering schools.

The future roadmap for OSILK focuses on expanding content—moving from basic awareness to deep dives into consumption, contribution, and launching open-source projects. There is also a strong push toward automation and localized translations to make open-source literacy accessible on a global scale.

Key Takeaway

The consensus among participants was that scaling education requires the same agility we apply to software. By adopting the Training-as-Code mindset, organizations can finally move past the “static slide” era and build a living, breathing knowledge base for the open-source community.

The cybersecurity topic stream at the first day of Open Chain and Friends event began with an impactful keynote from Dirk Targoni, spotlighting the critical connection between cybersecurity and open source. His practical session provided invaluable insights into navigating supply chain risks, emphasizing that effective remediation requires a holistic approach, not isolated solutions.

We gained clarity on essential factors: Asset Management (SBoM), Vulnerability Monitoring, Code and Binaries Checks, Pentesting, and robust Vulnerability and Incident Handling. A key takeaway was the interdependence of these elements – none are sufficient without the others. The session powerfully underscored that supply chain security has moved from the server room to the boardroom, driven by incidents where a single compromised dependency cascades rapidly.

Targoni also addressed the pervasive question, “Will AI take my job?” His reassuring answer: “AI is your assistant, can do the routine work for you”.

Following the foundational discussion on supply chain security, the cybersecurity session at Open Chain and Friends shifted focus to another rapidly evolving frontier: the critical importance of secure AI systems. Dr. Maike Massierer from Bosch took the stage, providing an insightful look into the topic. Her session highlighted the critical intersection of AI, cybersecurity, and regulation, especially within the automotive industry.

With AI increasingly powering automotive functions like road sign recognition and navigation, ensuring its security is paramount. Dr. Massierer demystified the EU AI Act, outlining its purpose: to ensure the safe and ethical use of AI across the European Union. Attendees learned about the serious implications of non-compliance and the vital importance of Article 15, which mandates AI systems to meet high standards of accuracy, robustness, and cybersecurity. Beyond regulation, the session offered practical insights into securing AI, with AI-specific Threat and Risk Analysis highlighting how crucial it is for addressing security needs effectively.

The OpenChain and Friends event took place between 24 and 26 March 2026, with various tracks spread over three different locations, all focusing on the challenges we face in the supply chain. I’m not very good at writing about details—nor am I sure I’m even allowed to, since if I do that, it wouldn’t be hard to figure out who was the source of the information, and the conference did take place under the Chatham House Rule—but I’m fairly confident in my abilities to synthesize. And one thing that stood out to me is that, regardless of whether we’re talking about infrastructure, software, data, or AI agents, what we’re dealing with is really one big supply chain with various facets.

Not only that, but it seems what we’re really trying to solve, in no small part, is the problem of trust. OpenChain is, of course, built around the cornerstone of creating trust in the open source software supply chain. Trust reduces friction and makes it possible for everyone involved to spend valuable time and resources on the things that are actually differentiating for one’s business.

But trust is also brought up when it comes to data – one needs to be sure that the data one is working with has integrity, that it has not been tampered with, that it does not infringe on anyone’s right to privacy, and that is of high quality. And the same applies to data spaces, which were quite heavily discussed in the AI track, regarding data provided by others.

Trust is also crucial for AI agents, which were also a topic presented in the AI track. There, I learned that 39% of US consumers have already used an AI agent to buy something online. This means that those 39% have provided an AI agent with a credit card. If we are to create an economy built heavily around agents, it’s quite clear that we absolutely need to emphasize the issue of trust, including trust in the underlying infrastructure.

And last but not least, trust would be a critical element in building a global system to manage the flow of vulnerability information, the topic of my talk on GVIP in the Cybersecurity track, where the conditions necessary to have trust in the system are explicitly formulated as a separate requirement.

The key takeaway from this three-day conference for me is the primary important we should all be placing on trust: trust in our infrastructure, trust in our software supply chain, and trust in our data supply chain. And if we are to have all of that, we would need to dedicate the necessary resources to create and implement the required standards and processes, and to build the necessary organizations, that make it possible to decide whom to trust and when.