Enterprise Technology Strategy Is Moving From Ownership to Participation

Enterprise technology strategy has always involved a fairly familiar set of decisions. Businesses decide what technology they need, whether to build it themselves or buy it from someone else, and how they'll manage it once it's in place. Some systems become company assets, while others are accessed through licences, subscriptions or supplier agreements. 

It's an approach that makes sense. Organisations need to know what they're spending money on, who's responsible for delivering it and how much control they'll have over the technology supporting their operations. Those questions aren't going anywhere, and neither are the traditional relationships businesses have with technology providers. 

But there's another relationship that doesn't fit quite so neatly into this model. Some of the technology businesses use every day is developed, improved and maintained through shared ecosystems involving organisations, developers and communities working towards common technical goals. 

An enterprise might build a commercial product using these foundations without owning them or having a conventional supplier relationship with the people who maintain them. That isn't a new arrangement. What's becoming more interesting is how businesses choose to engage with those ecosystems. 

Rather than simply using what others develop, some organisations are investing money, engineering time and expertise into improving the foundations they rely on. This raises a question for enterprise technology strategy. 

If participating in shared technology ecosystems can help businesses develop better products, influence technical decisions and strengthen their own capabilities, should it become a more deliberate part of how they plan their technology investments?

Enterprise Technology Strategy Starts With What Businesses Can Control

When a business needs new technology, it usually has two options. It can develop something itself or find an existing product that does the job. Building gives the business more freedom to decide exactly how something should work, although it also means taking on the cost and responsibility of developing it. 

Buying can save that effort, provided the available technology meets the business's needs. Of course, enterprise technology decisions are rarely quite that simple. A company might develop its own applications while using commercial cloud services to run them. It could license specialist software, outsource certain operations and maintain internal teams to manage everything together. 

Each decision creates a different combination of cost, responsibility and control. This is where the traditional build, buy and manage approach comes from. Technology strategy isn't only about selecting systems. It's also about deciding which capabilities the organisation should develop itself, which it should obtain from others and how those choices support its wider business objectives. 

Ownership and contracts provide useful ways to manage these relationships. When a business owns a system, it can make decisions about its development, maintenance and eventual replacement. When it purchases technology from a supplier, the commercial agreement helps define what the provider must deliver, what support is available and what happens when something goes wrong. 

Neither arrangement guarantees complete control, but both give businesses established ways to make decisions, allocate budgets and hold people accountable. They're also relatively straightforward to represent in technology portfolios, procurement processes and investment plans. 

The difficulty comes when an important technological capability isn't entirely produced within either relationship. Consider a company developing a new digital service. Its engineers might write the application, its cloud provider might host it and its technology suppliers might provide the databases and development tools. 

Yet some of those tools may themselves be built using software maintained by independent communities and multiple organisations working together. The company can own its application and manage its suppliers without owning or directing the development of everything that makes the service possible. 

Traditional enterprise IT strategy can account for the technology being used, but it doesn't always give the same attention to the shared ecosystems helping produce that technology. Understanding the difference begins with looking at what those ecosystems actually contribute.

Shared Technology Ecosystems Are Part of How Enterprises Build Capability

A shared technology ecosystem is a network of organisations, developers or other participants that collectively develop, maintain or improve technology used by more than one organisation. Participants may have different commercial interests, but their work contributes to a common technological foundation. 

Open-source software is one of the clearest examples. Instead of every business developing its own operating system, database or software development tools, organisations can use technologies that are developed collaboratively and made available under open-source licences. 

Some businesses contribute code, while others provide testing, documentation, funding or engineering expertise. The resulting software can then be used by organisations that weren't directly involved in developing it. The Linux Foundation's State of Global Open Source 2025, produced with Canonical, illustrates how established this model has become. 

In its global survey, 83 per cent of respondents considered open source valuable to their organisation's future, while 46 per cent reported that its business value had increased compared with 2024. The value goes beyond getting access to software without paying traditional licence fees. 

Shared development allows improvements made for one organisation's needs to become available to others. A performance improvement, new feature or compatibility update can benefit multiple businesses, even when they're operating in completely different industries. And open source isn't the only example. 

Public package registries, such as PyPI for Python software and Maven Central for Java-related components, provide shared services that developers use to publish and obtain software packages. These packages are reusable pieces of code that help developers add functionality without building every component themselves. 

Shared security infrastructure also contributes to enterprise capabilities. Certificate authorities, for example, help establish trust in encrypted online connections, while shared technical protocols allow systems developed by different organisations to communicate using agreed rules. These arrangements aren't identical. 

Some are community-governed, others have formal operators, and some combine commercial services with openly developed technology. What connects them is that they help organisations accomplish things through technological foundations developed or operated beyond their individual boundaries. 

For an enterprise, this changes how we might think about the source of technological capability. A business's ability to develop a product, integrate a service or improve its software can partly reflect work carried out across a much larger ecosystem. The business still creates its own value from that foundation. 

But when it wants the foundation to develop in a particular direction, simply consuming what others produce may not be its only option.

Participation Offers Something Ownership and Consumption Don't

Using technology and participating in its development are two different things. An enterprise can benefit from an open-source project for years without contributing anything to it, just as it can use a public software registry without becoming involved in how that registry operates. 

Technology ecosystem participation begins when an organisation takes a more active role in supporting, developing or influencing a shared technological foundation. That might involve contributing code, funding development, sharing technical expertise or taking part in decisions about a project's direction. 

The distinction is important because participation doesn't necessarily provide ownership. An enterprise contributing to an open-source project doesn't automatically gain the right to decide what happens to it. Its contributions may need to be reviewed and accepted by maintainers, while broader decisions can remain subject to the project's established governance processes. 

An organisation doesn't have to own a technology to have some influence over how it develops. Sometimes, getting involved in the work itself gives a business a better opportunity to address its needs than maintaining its own version of something that other people are already developing. 

Take an enterprise using an open-source database. Its developers need a particular feature, but the existing software doesn't quite support what they're trying to do. They could build the feature themselves and keep it within their own systems. That would solve the immediate problem, but they'd also have to make sure their changes continued working whenever the original database was updated. 

Alternatively, they could submit their changes to the people maintaining the database. If those changes are accepted into the original project, future versions could include the feature as standard. The business would still benefit from the work its engineers had done, but it wouldn't necessarily have to maintain that separate modification indefinitely. 

Developers call this an upstream contribution. Essentially, it means sending improvements back to the original software project rather than keeping them within the organisation that developed them. There's a commercial argument for this approach, even if other businesses, including competitors, can use the same improvements. 

The Linux Foundation explored the potential returns in its 2026 ROI for Open Source Software Contribution study. Using survey findings and an economic model, the researchers reported benefit-to-cost ratios of between two and five times for open-source contributions. The study also associated contributing upstream with faster responses to security issues, improved development speed and reduced effort maintaining private modifications. 

These findings don't mean every contribution will produce a financial return. The results combine reported organisational experiences with modelled estimates, and the benefits will depend on the technology, the contribution and the organisation involved. Still, they help explain why contributing to shared technology can be a business decision rather than simply an act of goodwill. 

An organisation might contribute engineering resources because it wants a feature developed, provide funding because it needs reliable ongoing maintenance or participate in technical discussions because future changes could affect its products. In each case, the business has its own interests. 

The difference is that pursuing those interests through a shared ecosystem can also improve technology used by others. This creates an interesting relationship between private competitive advantage and collective development. Businesses don't necessarily have to keep every technological improvement to themselves to benefit commercially from making it. 

Sometimes, having a better shared foundation allows them to concentrate more of their resources on the products, services and capabilities that genuinely distinguish them from competitors. The strategic value comes from understanding when participation offers something that purchasing, internal development or passive consumption cannot achieve as effectively.

Enterprise Participation Is Becoming More Deliberate

Enterprise involvement in shared technology isn't new. Large technology companies have contributed to open-source projects and participated in industry groups for years. What's worth examining now is how some organisations are bringing those activities closer to their formal technology decisions. 

One indication comes from the growing role of open-source programme offices, usually called OSPOs. These are teams that help organisations manage how they use and contribute to open-source technology. Their responsibilities can include licensing, internal policies, community relationships and decisions about where the business should invest its development resources. 

Traditionally, an OSPO might have focused heavily on making sure employees used open-source software correctly and complied with licence requirements. Those responsibilities remain important, but the role can extend into technology selection, engineering collaboration and wider business strategy. 

The Linux Foundation and TODO Group's 2026 State of OSPOs and Open Source Management provides evidence of that broader involvement. Among OSPOs participating in AI decision-making, 85 per cent were involved at or before technology selection. The report also found that 79 per cent of OSPOs involved in AI governance actively contributed to activities including policy development, evaluating open models and managing related risks. 

These figures don't tell us how many enterprises are contributing to shared projects, and involvement in internal governance isn't the same as external participation. They do, however, show that some organisations are bringing specialist open-source expertise into decisions that previously might have been handled mainly through procurement or individual development teams. 

There's still a considerable difference between recognising the importance of shared technology and developing a formal approach to it. The Linux Foundation's 2025 global research found that only 34 per cent of surveyed organisations had a defined open-source strategy, while 26 per cent had established an OSPO. 

That gap suggests formal organisational approaches haven't caught up with the value many businesses already see in open source. An even more direct example emerged in September 2026, when the Open Source Security Foundation (OpenSSF) published its We're In: Enterprise Commitment to Sustainable Package Registries statement. 

Backed by organisations including Microsoft, Google, IBM, GitHub, Red Hat and Dell Technologies, the statement supports the development of funding models through which enterprises can help pay for public package registries they use commercially. 

It recognises that organisations benefiting from these services at scale have a commercial interest in supporting their continued development. What's particularly interesting is how the commitment describes the proposed relationship. Participating enterprises would be willing customers of independently operated registries, rather than seeking to own them or dictate how they should be managed. 

The statement doesn't establish that a new funding system has already been adopted across the industry. It represents support for exploring and participating in those arrangements, with individual registries retaining control over their own models. Even with that qualification, it's a useful example of enterprises considering a different kind of technology investment. 

Instead of purchasing a product outright or contracting a supplier to develop a private solution, they may contribute financially to infrastructure that continues to serve an entire ecosystem. That approach brings shared technological foundations into a conversation usually reserved for internal development budgets, commercial software and supplier agreements.

What Participation Could Mean for Enterprise Technology Strategy

For enterprise leaders, the question isn't whether participation is inherently better than ownership. It's whether there are situations where becoming involved in a shared technology ecosystem could help the business achieve something it wouldn't accomplish as effectively by simply using the technology. 

That requires a slightly broader view of enterprise technology planning. Consider how an organisation might approach an important software platform today. Its technology team could evaluate available products, compare suppliers, estimate costs and decide whether the platform meets its requirements. 

If it chooses to use the technology, the next steps usually involve implementation, integration and ongoing management. Those decisions are still necessary. But if the platform is developed through a shared ecosystem, there may be another question worth asking: could the organisation benefit from participating in how that technology develops? 

The answer will depend on what the business is trying to achieve. An enterprise developing specialist software might benefit from contributing improvements to a shared framework, particularly when those improvements could reduce the amount of custom code its engineers need to maintain. 

Another organisation might find greater value in supporting a common technical standard that helps its systems work with products from different providers. A company relying on public development infrastructure might consider financial participation, while a business with specialist security expertise could contribute that knowledge to a shared project. 

These are different forms of strategic technology participation, and they shouldn't all be treated as equivalent. Contributing engineering work involves different costs and opportunities from funding a service or participating in governance discussions. How much influence a business gets will also depend on how it participates. 

Paying to support a shared service, for example, doesn't necessarily give an organisation any say in how the technology is developed. Contributing code is a more direct way of getting involved, although the people maintaining the project still decide whether to accept it. 

Businesses need to understand these differences before deciding where to invest their resources. A contribution that helps reduce the amount of custom software a company maintains might be worth the engineering time involved. 

But if the goal is to influence the direction of a project, the organisation would need to understand how decisions are made and whether there's a realistic opportunity to take part. There are practical considerations too:

• Does the business have people with the right expertise?
• Can it afford to dedicate their time to work that isn't exclusively for its own use?
• And is the technology important enough to justify an ongoing commitment, rather than a one-off contribution?

These are questions that belong in technology planning alongside the more familiar decisions about development, procurement and suppliers. This is where technology ecosystem strategy begins to look different from conventional supplier management. A supplier relationship is usually organised around a defined exchange. 

The enterprise pays for a product or service, and the provider accepts certain obligations in return. Participation in a shared ecosystem can be less direct. Contributions may benefit several organisations, decisions may be made collectively and the commercial return may come through improvements to the underlying technology rather than a service delivered exclusively to one customer. 

That makes participation harder to assess using the same measures applied to ordinary procurement. A business might not receive a dedicated feature or exclusive service in return for its investment. Instead, it could benefit from a stronger common foundation that supports its own products and operations. It also means participation needs to be selective. 

An organisation doesn't have unlimited engineering capacity or technology funding. Contributing to every shared project it uses would be neither practical nor necessarily valuable. Some technologies will remain best managed through existing commercial relationships, while others may offer opportunities for more direct involvement. 

The strategic change, then, isn't about replacing build-or-buy decisions with a new requirement to contribute. It's about recognising that participation can be another option when enterprises consider how to develop, maintain and improve their technological capabilities. 

Once that possibility becomes part of the discussion, technology leaders can make more deliberate choices about where their organisation should remain a consumer and where becoming a participant could provide additional value.

Participation Doesn't Replace Ownership or Control

It's tempting to describe this development as a move away from ownership altogether, but that would misunderstand how enterprise technology works. Businesses will still need to develop proprietary systems, purchase commercial products and manage suppliers. 

Ownership can provide valuable control over technology that directly supports a company's competitive position, while contracts remain essential for defining service expectations and commercial responsibilities. Participation doesn't remove those needs. Nor does it guarantee that an organisation will gain the influence it wants over a shared project. 

An enterprise can invest substantial engineering resources into a community-developed technology without securing agreement on its preferred direction. Funding a shared service might improve its ability to operate, but it doesn't necessarily give the contributing organisation control over future decisions. 

There are also costs to consider. Engineers working on shared projects aren't available for every internal development task, and participating in governance activities requires time and expertise. Businesses need to weigh those commitments against other ways of achieving the same objectives. Different ecosystems will also require different approaches. 

Some have established processes for accepting external contributions, while others provide limited opportunities for organisations to become directly involved. Commercial services built around shared technology may offer their own participation arrangements. So the choice isn't simply between owning technology and contributing to it. 

An enterprise might own some capabilities, purchase others and participate in shared development where doing so supports its interests. Participation is an additional strategic option, not a universal obligation. Its value comes from understanding what involvement could achieve and whether that outcome justifies the resources required. 

That distinction allows enterprise technology strategy to evolve without abandoning the established approaches that continue to serve businesses well.

Final Thoughts: Enterprise Technology Strategy Needs to Look Beyond Ownership

For a long time, enterprise technology strategy has been organised around a practical question: what should the business build, buy and manage? Those decisions remain central to how organisations develop capabilities, allocate resources and maintain control over their technology. 

But they don't describe every relationship involved in creating those capabilities. Shared technological ecosystems allow businesses to build on work developed and maintained collectively, often by people and organisations they don't own or directly manage. The emerging opportunity is to think more deliberately about what businesses can gain by participating in that work. 

Research into open-source contributions suggests there can be commercial benefits, while recent industry commitments show that some enterprises are exploring ways to support shared infrastructure through more formal investment arrangements. None of this means participation is replacing ownership or becoming necessary for every organisation. 

It suggests that enterprise technology leaders have another relationship to consider when deciding how best to support their business objectives. The next evolution of enterprise technology strategy may therefore be less about owning additional technology and more about understanding when participation can help organisations develop stronger capabilities. 

As shared technological foundations become part of more enterprise decisions, EM360Tech will continue exploring what these changing relationships mean for the way businesses invest in, manage and shape the technology they use.