OSPOlogyLiveLyon 2025 Presentations, Demos & Roundtable Notes

[anajsana]

Creating a thread for the OSPOlogyLive Lyon presentations, demos, and roundtable notes. Please add your slides, materials, and summary notes as new comments to this thread via like (e.g, Google Slides, SpeakerDeck, etc) or PDF upload.

[dbrownlf]

Cross-Border Collaboration in Energy Innovation Roundtable (Introductory slides for the roundtable discussion) - https://docs.google.com/presentation/d/1OPmgMKtGok0UnxEp5vWaCEQeJ1hBxpiGXD0PDimUsAA/edit?usp=sharing

[geekygirldawn]

Here's a PDF file with my slides: Demonstrating Value OSPOlogy Lyon 2025.pdf

I'll be talking about the materials in this guide, so here's a link to make it easier for people to find: Practitioner Guide: Demonstrating Organizational Value

[stephenkilbaneadi]

PDF for Company Use Cases: A Guide to OSS Contribution and Management.
TODO-EU-Chapter-Company-Use-Cases-A-Guide-to-OSS-Contribution-and-Management.pdf

[anajsana]

Welcome Slides Day 1 google doc

[gkunz]

Here's my slide deck.

[japlux]

PDF for What could go wrong with open-source? Lessons learned from collaborative research projects with industry here

[GeekoOnTour]

Here are my slides for my presentation on Eurostack, OSS and Sovereignty.
Emiel Brok, SUSE
https://docs.google.com/presentation/d/e/2PACX-1vT9f3jd0aq-8deR2JqtEzY3d_xCI8aAqw1W8y_qf9UfEwVR3sj2JDkZensrm2HYXT2B1lQ1AzfWQrRP/pub?start=false&loop=false&delayms=60000
OSPOLogyLive Lyon 2025.pdf

[lucian-balea]

Here are my slides for my session on maturity & the value of foundations:
OSS Maturity and Value of Foundations - LBalea.pdf

[bzg]

Here are my slides: https://bzg.fr/uploads/bastien-guerry-swh-05112025.pdf

[mafesan]

Here are the slides for the CHAOSS - GrimoireLab workshop, from the Collaboration Marketplace session:
Getting Started with GrimoireLab and Augur tooling for Project Health.

OSPOlogy Workshop_ GrimoireLab 2.x + CI_CD-2.pdf

Other links:

• GrimoireLab Dashboard for CHAOSS project: https://chaoss.biterg.io
• GrimoireLab 2.x Demo & Trustable Software Framework, analyzing the dependencies from freedesktop-sdk: https://gitlab.com/Bitergia/freedesktop-sdk-trustable-metrics.

[geekygirldawn]

SaaS instance of Augur for the Getting Started with GrimoireLab and Augur tooling for Project Health Collaboration Marketplace: https://metrix.chaoss.io/

Short presentation about Augur / 8Knot:
Augur-8Knot.pdf

[ibrahimhaddad]

Talk: OSPOs: From Inception to Strategic Pivoting and Geopolitical Shifts
Speaker Ibrahim Haddad
Download slides

[jerpelea]

[like] Jerpelea, Alin reacted to your message:

…

________________________________ From: Ibrahim Haddad ***@***.***> Sent: Wednesday, November 5, 2025 11:36:22 AM To: todogroup/ospology ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [todogroup/ospology] OSPOlogyLiveLyon 2025 Presentations, Demos & Roundtable Notes (Discussion #696) Talk: OSPOs: From Inception to Strategic Pivoting and Geopolitical Shifts Speaker Ibrahim Haddad Download slides — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this Talk: OSPOs: From Inception to Strategic Pivoting and Geopolitical Shifts Speaker Ibrahim Haddad<https://urldefense.com/v3/__https://www.linkedin.com/in/ibrahimhaddad/__;!!O7_YSHcmd9jp3hj_4dEAcyQ!whRrk_sADgsDbCP7wUy_lvWydIIWMG3sNgEDdTwWIq_Detuwwzb7Tk7lKfcjdcqjfw8MjhGVvGIS4bEv9JTyZw8XPw$> Download slides<https://urldefense.com/v3/__https://github.com/user-attachments/files/23358747/OSPOlogy.Ibrahim.Haddad.pdf__;!!O7_YSHcmd9jp3hj_4dEAcyQ!whRrk_sADgsDbCP7wUy_lvWydIIWMG3sNgEDdTwWIq_Detuwwzb7Tk7lKfcjdcqjfw8MjhGVvGIS4bEv9JS7vU7BMA$> — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/todogroup/ospology/discussions/696*discussioncomment-14880113__;Iw!!O7_YSHcmd9jp3hj_4dEAcyQ!whRrk_sADgsDbCP7wUy_lvWydIIWMG3sNgEDdTwWIq_Detuwwzb7Tk7lKfcjdcqjfw8MjhGVvGIS4bEv9JTHMou5Og$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AB32XCWNFXOKST4JYSI2N5L33HOLNAVCNFSM6AAAAACJVDGKQKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIOBYGAYTCMY__;!!O7_YSHcmd9jp3hj_4dEAcyQ!whRrk_sADgsDbCP7wUy_lvWydIIWMG3sNgEDdTwWIq_Detuwwzb7Tk7lKfcjdcqjfw8MjhGVvGIS4bEv9JRcYQhMKQ$>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[anajsana]

Roundatable Notes - Industry Academic Collaboration

Attendees introduction: coming from industry and academia to enhance tech transfer, research centers, and organizations looking to strength connection with acamia through programs and training courses / build more ecosystem within academia

[anajsana]

Different languages and contexts: academia and industry often use the same words but mean different things:

• Open source in academia is frequently framed as “source code to support a publication,” whereas in industry it may be seen as a product, infrastructure component, or strategic asset
• There are persistent myths in universities regarding licensing, such as:
• Copyleft-licensed code being inherently restrictive or unusable
• The belief that a project must choose only one license without flexibility
• These differences contribute to misunderstandings and slow decision-making around collaboration

Factors that prevent companies from engaging more deeply in open source projects from industry

• Lack of awareness of open source governance models and contribution pathways
• Difficulty in quantifying the value of open source participation in traditional business metrics
• Perception that open models are less controllable or harder to manage from a risk and IP perspective

The Technology Transfer Gap

• Students and researchers often develop open source tools and gain strong OSS habits at university. However, once they graduate, projects may lose momentum if there is no clear pathway to industry adoption or sustained funding
• If investors and leadership better understand open source business models, research-originated OSS projects are more likely to find viable industry use cases and continuity beyond academia

Why Companies Engage with Universities?

• Identify and recruit skilled talent early
• Explore new technologies in low-risk environments before committing internal resources
• Participate in community-driven projects that align with long-term strategic interests

[anajsana]

IP Clarity and Dedicated Coordination

• Academic researchers often need strong institutional support around intellectual property to feel confident collaborating with external partners. At the same time, companies require clear expectations regarding licensing, code ownership, and publication timelines before committing resources
• A key success factor identified was having a dedicated person or team responsible for leading these conversations early in the collaboration process. Without clear coordination, projects stall not for technical reasons, but due to ambiguity or misalignment around IP and compliance.

An Academic OSPO (or OSPO-like function) can serve as the bridge between research groups and industry partners. Their responsibilities include:

• Guiding conversations about open source licensing strategies.
• Clarifying contribution agreements and IP assignment expectations.
• Addressing misconceptions and harmonizing different organizational cultures.
• Providing templates, guidance, and repeatable processes to accelerate collaboration.

Thus, when an Academic OSPO (dedicated person / team )is involved from the beginning, universities and companies can be able to:

• Move more quickly from concept to joint project
• Reduce negotiation overhead and confusion

The group agreed to see more Academic OSPOs take on this role within universities, providing structure, continuity, and shared understanding across both communities.

[anajsana]

Issues and Needs Identified

• Are there existing guidelines or frameworks that describe different models for how academic institutions can develop and release open source projects? If not, would creating a shared typology be valuable for helping universities adopt consistent and effective approaches?

• When industry approaches academia to collaborate on a project, it is often unclear whether the intention is to keep the results proprietary (under company IP) or to develop them openly as open source. From the academic perspective, what challenges arise when trying to move a project toward open source while still addressing institutional IP policies and requirements?

[bzg]

Are there existing guidelines or frameworks that describe different models for how academic institutions can develop and release open source projects? If not, would creating a shared typology be valuable for helping universities adopt consistent and effective approaches?

Perhaps there are two mixed elements here:

1. A typology for the different kinds of software that academics produce:

   • Code attached to a scholarly publication
   • General-purpose utilities, aimed at the needs of researchers
   • Full-fledged research project, specific to a research area

2. A list of development (or life-cycle) models:

   • organic ("scratch an itch")
   • spec-based (using known referentials, etc.)
   • closed then publicly shared
   • ...

[anajsana]

A key takeaway is the need to better align the value proposition of collaboration for both academia and industry.

Universities often default to strong IP protection, partly due to institutional policy and partly because maintaining IP portfolios is seen as a marker of research value. But there are hidden costs (Ongoing IP maintenance fees, Administrative overhead in managing patent portfolios,)... Ambiguity around IP ownership or licensing slows industry engagement.

Recommendation: Hosting academic-origin projects within a recognized open source foundation can:

• Reduce institutional pressure on IP ownership and maintenance
• Provide neutral governance and well-established contribution workflows
• Create a sustainable ecosystem that outlives individual research groups or student cohorts
• Increase industry confidence and willingness to invest time, resources or adoption

[GeekoOnTour]

Academic Track: addition:
From Default proprietary to Standard OSS

• can we learn from successes in the past?
  (f.e. MatLab -> Python, Rust, R)
  (f.e. VM Ware -> Proxmox)
  Was it always be the Proprietary company made a mess?
  Or was it (also) thanks to the flexibility and innovative possibilities with OSS?

Closing software is not always successful.
Mital mentions that creating an IP that is resistant is not easy nor cheap and therefor risk-free.

[dbrownlf]

Roundtable Notes - Cross Border Collaboration for the Energy Transition

Why are only a few utilities from a few countries members of LF Energy?
-There are actually far more consuming it, and even contributing to it in some cases, but not all are paying membership dues.
-Vertical initiatives have to be led by end users. Tech vendors don’t like the model which can be directly contrary to their existing business model. In telecom, open source initiatives were driven by network operators for example rather than the vendors. This was easier because telcos are also IT companies; utilities are not IT companies for the most part, so they are less likely to launch this sort of initiative. We are seeing some movement in the direction of at least looking at open source. IT scares, and open source scares more. There’s work to be done with other utilities to educate them. It’s important to go to events that are not only energy IT, but energy generally as you have to convince the broader utility community rather than only the tech folks.

Vertical industries have to decide whether to make or buy. Many are deciding to make more, but are not necessarily going the open source route. Is it an awareness issue?
-Often it is a bottom-up push, with the developers being the ones who are encouraging open source, but they run into objections from the management level. They have a variety of pain points and preconceived ideas about open source - you lose budget by using free software (untrue since you need to pay for deployment and maintenance); it’s not secure; it’s not reliable. This is a cultural issue that requires a culture change to address it. There also needs to be a vendor or service provider ecosystem so the manager has someone “to blame” when something goes wrong.
-Telco went through the same thing; it was all black boxes and just buying boxes and wires. They had to change and adapt and learn the technology to advance.
-Energy and other verticals have no choice but to build ICT departments. They cannot just keep buying equipment from vendors and plugging it in. Regardless of industry, they all are digitalizing because it’s necessary for advancement and efficiency, and that will necessitate having technical expertise in house.

What about utilities building an IT service subsidiary?
-Utilities don’t have the mindset of IT companies. This has been tried by utilities in the past and they decided to move open source instead because it was better to work with a community with competence in tech rather than try to build that competence from scratch.

Is it better to only host our own open source events to evangelize about these solutions for the energy industry, or to go where the software companies are at?
-All of the above. We need open source to interoperate with proprietary. It’s important to go and meet folks not already involved or even aware of open source to introduce them to it. It also helps to attract more contributors. Don’t only focus on verticals, but also technologies that are applicable across verticals.

Collaboration across utilities:
-The utilities that are furthest along are still only in the R&D phase. They need to next figure out how to shift actual OT to become IT.
-SCADA systems are the core of power systems. But they are not upgradable; they’re usually specified for 10 years, then get replaced. One utility has decided to break that cycle and bring in an IT approach and build a modular solution. This type of innovative approach presents an opportunity for other utilities to learn from them. However it’s a closed source solution so there’s not a great opportunity to do this from an open source perspective right now. There is still some learning from this because off-the-shelf didn’t work so they had to develop it, now the challenge is to convince them to take that open source to benefit from further collaboration.
-Utilities already have their own solutions installed and think they work. They don’t have an incentive to change to anything – open source or not – unless you can provide that you have a better solution. The only way to do this is to actually meet with these folks, show them how your solution works and the ROI. There are events specifically for this audience that are an opportunity to meet them.

What about standards? Those are already forcing collaboration with other countries.
-Utilities are local monopolies subject to regulation.
-Open source needs to be motivated by some pressure externally. For example IBM wanting to kill Microsoft’s supremacy in operating systems. Google wanting to kill AWS’ supremacy in cloud.

Challenges
-When someone in another country wants to test an existing open source project used by a utility in a different country, it requires work on their part to test. It’s not a commercial product with implementation or alpha testing support. Who pays for it? Who spends time to do it? Who answers questions? There’s the option to hire consultants, but not everyone has the budget. The open source maintainers want others to adopt their project, but they don’t have time or resources to help those users.
-There’s always going to be concerns over long term support, especially with SCADA systems with 10 year lifespans, or substation tooling with 20-30 year lifespans. Need to better explain to folks that open source is actually more supportable as it’s not reliant on a single vendor. In the world of digital sovereignty concerns, that’s also something to consider since often the big vendors selling into Europe are American, and there are concerns about becoming reliant on them long term.
-Even when you get the decision maker to consider an open source solution, it is a long evaluation process. They are often used to long procurement processes and want to do the same sort of review process for open source. It’s also hard to get time with the top level (c-suite for example), so there’s little opportunity to convince them of the value or to take a risk.
-Sometimes the decision maker comes before the architects are even involved. They sign off on a procurement process then tell the architect to implement it.
-Have to address concerns around long term maintainability. What happens if the lead maintainer dies? What is the SBOM? What’s the service provider ecosystem? How does this fit under regulations such as NIST, CRA, etc.?

Starting points for cross-border collaboration
-There are existing networks for collaboration between TSOs in Europe because they have to work together to some extent. We should leverage these as a starting point to have these discussions. This is organized at the EU level. The problem is they require consensus to agree to anything.
-Rather than look for a complete cross-border consensus, we need a venue for end users to discuss problems and solutions, and they don’t necessarily have to agree on the solution.
-Linux Foundation can serve a convening function to some degree, but it can be too technical for many end users. There is a need for something more general/business-focused.
-Look at other open source projects and what they are doing. What’s on the market, what can vendors provide, what doesn’t exist. Learn from all those communities. Also companies need to understand what capabilities they have themselves in house.
-So many organizations do not understand that they are already using open source, it’s important to give them easy ways to get a view into that as part of the process of convincing them that it’s a valuable solution.
-Focus on educating the enterprise architects who can make the link between business needs and technologies about open source. That way they can translate for the business audience the value of open source and convince them to consider it. Start by helping them consume open source, then move them up the chain towards contribution.
-There are innovators everywhere with organizations. For railways, there are folks looking to innovate on the tracks, the engines, the platforms, the station causeways, etc. We should not limit ourselves to IT departments, but need to look for who is responsible for innovation across all parts of the organization. This creates an even bigger challenges though as it means there are clusters within clusters, making it even harder to work across departments, organizations, and borders.
-For the c-suite, we should do two things: show them how much they’ll save by using open source (would cost $X to develop or buy this); and/or show what they’re going to miss by not using open source (extra cost, lower revenue).
-Collaborating with the external world could help with internal collaboration. By showing that a process or project is becoming the standard across national boundaries, it can convince skeptical stakeholders to consider them. For example, one utility tried doing its own internal development projects and found that they were not meeting the goals. By then taking those projects open source they collaborated with others, learned from them, adopted best practices from a broader community, and the projects transformed into being highly successful. Key to this were adopting open source best practices they hadn’t known previously, and an open governance model that empowered technical leads to be able to make their own decisions. “Open source is not a matter of technology, it’s a matter of transformation of organizations.”
-It can be easier to have collaboration within the company, start outside the company.

What about cross-vertical collaboration?
-The Linux Foundation can serve as a convening authority for this type of collaboration, but we need to understand the need. This could be subprojects, subfoundations, etc.
-Getting a variety of end users in different industries from different countries together can be a valuable lobbying tool, for example to the EU Commission. There are already working groups on this at the EU level.

[dbrownlf]

Day 2 notes:

When TSOs talk to each other, they do so as peers. However even though they are not competitive, they want to protect and grow their own reputations. They are never neutral. Open source foundations create a neutral environment where everyone can speak freely with no personal interest, enable more innovation.

Railroads have digital substations, which one energy utility only recently learned. In fact, many folks at the railroad didn’t know it. The two organizations are now looking at ways to learn from each other in a cross-industry collaboration, and the railroad is even looking at LF Energy SEAPATH.

There are also similar constraints between telecommunications and energy that are similar for both industries. This is leading to a potential cross-vertical collaboration at the CNCF level which is a huge benefit.

When energy utilities get involved with open source foundations, it can change the internal culture of the utility and influence their approach going forward. A learning from political science is corruption studies - when you have a corrupt government, you start with “islands of purity” and grow them slowly over time; the same can be applied to changing an internal culture to be accepting of open source. You start small and place the “pure” folks throughout the organization.

Similarities to inner source program offices - sometimes these organizations are already doing that, can it start as spreading these inner source best practices and expanding them into open source.

There are many organizations across verticals, countries, etc. that are operating in silos, which is a shame because they have the same challenges and goals. Need to find a way to bring those disparate groups together. Start with internal to the organization as there are often different teams/departments working on similar issues but not doing it together. Bring together different technical skills, standards, knowledge bases, to work jointly on a problem. These silos can only be solved with external influence.

One solution is to compare the ROI when we are siloed internally versus implementing a collaborative, open solution. It’s important to put a euro/dollar number on it. If you can tell an EU commissioner that one solution can fix a challenge for railroads, energy utilities, and telecommunications providers, he would be very happy to help break that silo. There’s a desire to do research on that ROI for open source, and potentially add a section to the research on the value of inner source.

Even if a company is only doing inner source, engaging with open source communities will make them better at it because they will learn best practices and not reinvent the wheel. And eventually open sourcing inner source projects can actually lead to more awareness within the company; sometimes other teams won’t know that a solution exists within their own organization until it’s released as open source publicly. In the early days of a company (even a long standing one) starting to use and build software, a huge amount of time is wasted because teams are not collaborating and sharing what they are working on. An OSPO can help solve this.

This analogy can also be expanded to different countries not talking to each other rather than different departments within a company, however the external force will be different as they don’t all report to the same boss.

A catalyst is always needed. It could be high level management; it could be ROI.

Thinking in larger perspective can help. Look at what the full stack should look like. That means when working on one part, you need to consider what it’s integrating with, which will help force collaboration across departments at minimum.

Also what stack already exists that can be used in different ways?

There’s a different financial model in the R&D phase versus production phase. It’s hard to fight silos in the production phase, but there’s opportunity during R&D. Magic can happen when open source and open standards are implementing during R&D phase, including in academic research. Once equipment and solutions are in production it’s harder to fix interoperability issues.

Planting the seed while folks are in school or academia helps, but isn’t the only way. It’s important to find the people who believe in this within organizations to start to build “islands of purity”, but it’s also important to find these people across organizations. And when the islands are built within an organization, some of them need to leave for other organizations; that builds networks and spreads the culture more broadly enabling more inter-organizational collaboration. This is a part of starting to build a community. From there it can grow organically and will naturally be outside of silos. It’s nothing that will automatically happen, and there can be pushback. The communities need to be welcoming and easy to access; if the community is open and its projects and assets are easy to find then it will grow even more and evolve.

Some multi-country regulations like NIST-2 only require the end goal, and let the countries decide what mandates to put in place to achieve it. This leads to dozens of standards and for vendors it’s going to be incredibly difficult to build solutions that adhere to all of them. If these countries worked together on a single standard it would be more effective and ensure interoperability.

We have to keep in mind different peculiarities between different countries. They are at different stages in terms of open source generally. There has to be thought about how to start conversations between different countries at different levels of maturity. There are also conflicts of laws and regulations. Political change and elections are also a risk, so it’s important to educate the government and politicians in a non-partisan way. This is one reason it can be better to work through EU institutions rather than national governments as they tend to be more bureaucratic and long lived. The digital sovereignty topic is helping though, as it is a catalyst for this type of conversation. It actually provides a unique incentive for this type of collaboration in Europe.

[madalinnneag]

here is my (updated) presentation:
OpenSSF And its Cybersecurity Skills Framework.pdf

[nicorikken]

Roundtable Notes - Open Source Management - Day 1

20251105-OSPOlogyLive-Lyon-Open-Source-Management.drawio

• TODO Group guide
• https://github.com/Open-Source-Compliance/Sharing-creates-value/blob/master/Tooling-Landscape/CapabilityMap/OC_ToolingChain_v1.6.5.pptx
• No complete software seem to exist
• Maturity model
• More guidance might be coming from CRA
• Capability map for open source compliance tooling: https://github.com/Open-Source-Compliance/Sharing-creates-value/blob/master/Tooling-Landscape/CapabilityMap/OC_ToolingChain_v1.6.5.pptx
• Grimoirelab risk analysis in dependencies
• Mapping to commercial support?
• Eclipse Trustable Software Framework https://projects.eclipse.org/projects/technology.tsf
• Challenge of risk assessment: depends on the user.
• License review is more straightforward as it is quite quantifiable. Risk assessment is more grey.
• Idea: risk metrics on each component. Base policy broad for the organization, which can be made more strict for certain projects.
• Similar to licensing: export control and trade compliance
• The process of codifying use-cases is cutting-edge and might need a workgroup effort.
• It helps if organizations share their approach, so other organizations can point to those examples to convince on the approach and get buy-in.
• Developer input plays a key role. They should understand the question. Training?
• Example: training with basic licensing information and by telling who to contact in case of questions. This can be an ambassador program.
• Where to develop a training? OpenSSF Best practices SIG or TODO Group.
• Training for risk, not just license compliance?
• CODE certification has the content, but it a certification.
• Example of information is https://github.com/ossf/wg-best-practices-os-developers/blob/main/docs/Concise-Guide-for-Evaluating-Open-Source-Software.md
• When to do a deeper assessment and not just metrics? For example when a library becomes more critical.
• Terms are also used differently, like 'risk' and 'health'.
• How to get into a common workflow that follows a standard process. First have to have a process that then people can follow.
• TODO Group maturity models: most if not all of compliance is in maturity model 1, so no distinction in maturity model. https://todogroup.org/studies/evolution/
• Idea to get more urgency: do an internal audit according to CRA or NIS2 requirements.
• Influence from OSPO perspective: stick and carrot.
• How to approach business management about issues on license compliance. Should there be some training? They might not have a software background.
• Real-world situations can help to highlight and illustrate risks.
• Fine can also can help raise awareness.

[nicorikken]

Roundtable Notes - Open Source Management - Day 2

• What is needed to support the processes?
• What can open source companies do to help the energy sector?
  • Lower in the digitalization stack (like SEAPATH), there is a lack of open source companies to support is.
  • These companies can bring their expertise of support and maintenance on these new areas, which are often lower than the large companies are willing to go.
  • Idea: have grid operators create a joint ventures to create the support organization that is needed by pooling experts.
  • It is a challenge to get commercial involvement in open source ecosystems because of the expertise needed for the software.
  • Real-world example: OpenKAT developed for a need by the Dutch ministry of Health, which they now want to spin out into a commercially supported ecosystem.
    • Continuation is pursued in the Dutch Open Source Business Alliance.
• Much work to be done is typical maintenance work that does not require specific expertise other then software development.
• Incentive is different for each contribute. You can not always just pay for support or maintenance.
• Business would need a long-term commitment. Commitment on use of the usage of the open source project and commitment on the business around it.
• Real-world example of Spotify: reviewed the used libraries and turns out there was a particular library they relied on heavily, but was maintained by a single developer. Spotify started supporting the developer.
• Example of October 2024 by Welotec with RedHat as demonstrator to run SEAPATH. Still hard to get full support.
• Best way to grow the community is to have a commercially supported ecosystem so that organizations with fewer in-house capacity can get started.
• If open source projects are not supported, you better make sure you have the buy the support or maintenance or have the expertise yourself to do so.
• Different terminology: to have a core project, with an emerging problem that appears and you have to address. You can keep doing it yourself or create a spin-off to handle it for you.
• A common approach to open source by companies is to not want to deal with it and then want to have a commercial company to handle it for them.
  • A more mature open source open source stance for an organization would be to view of the open source community as a provider to build a relation with.
• Getting back to Spotify case, one can provide a financial reward for listed maintainers.
• To fund maintenance, you need companies to engage in communities.
• There is a also a role for open source business associations to point you to supporting companies.
• For a company there is an initial cost to get involved in an open source project.
• To convince somebody in the company it might sometimes be better to pursue the change via an outside actor.
• Management should also understand the specific aspects of digitalization and open source, because maintaining the status quo of procuring software.
• Not discussed: how communities want to interact with enterprises.