Open Source Doesn't Mean No Asset Management

For many organisations, Software Asset Management begins with a familiar list of commercial software vendors: Microsoft, Oracle, IBM, SAP, VMware and others.

Open-source software often sits outside that conversation.

It shouldn't.

The assumption that open-source software does not require Software Asset Management is becoming increasingly difficult to sustain as organisations rely on enterprise distributions, commercial subscriptions, support agreements, container platforms and open-source technologies embedded throughout their technology estates.

Red Hat, SUSE and other vendors have built substantial commercial businesses around open-source technologies. The software may be open source, but the commercial relationship surrounding that software can be anything but simple.

That creates a significant opportunity for organisations to apply SAM principles beyond traditional proprietary software.

Open source and commercial software are not opposites

The first misconception to address is the idea that software is either "open source" or "commercial."

In reality, the two can coexist.

An organisation may freely obtain and use open-source software while purchasing a commercial subscription for:

• Enterprise support

• Security updates

• Certified versions

• Technical support

• Management platforms

• Cloud services

• Extended lifecycle support

• Enterprise repositories

• Additional functionality

• Vendor indemnification or other contractual benefits

Red Hat is a particularly good example.

The underlying technologies associated with Red Hat's ecosystem are heavily rooted in open source, but organisations can have significant commercial relationships with Red Hat covering products and services such as Red Hat Enterprise Linux, OpenShift, Ansible Automation Platform and application platform services.

The result is a very different SAM challenge from simply counting software installations.

"It's open source" is not a SAM strategy

An organisation might have thousands of Linux instances running across its environment and still have very little understanding of its commercial position.

Questions quickly become more complicated:

• Which systems are running enterprise-supported distributions?

• Which systems require subscriptions?

• Which systems are physical and which are virtual?

• How are virtual machines allocated to physical hosts?

• Which workloads are running in public cloud?

• How are clusters configured?

• Which subscriptions cover which environments?

• Are development, test and disaster recovery environments included?

• Are systems being retired but subscriptions remaining active?

• Are subscriptions assigned to the right environments?

• Are different products being used together in a way that creates additional commercial requirements?

These are Software Asset Management questions.

The fact that the underlying technology is open source doesn't make them disappear.

The difference between software and entitlement

One of the most important concepts when managing open-source software is separating the technology deployment from the commercial entitlement.

Consider a simple example. An organisation might have:

2,000 Linux servers

That number tells us very little about its actual commercial position.

A SAM analysis needs to understand the characteristics of those servers.

For example:

Technical information	Why it matters
Operating system	Determines the relevant product family
Version	May affect subscription and support requirements
Physical / virtual	Can affect licensing calculations
CPU / cores	May be commercially relevant
Host relationship	Important in virtualised environments
Cluster membership	Can affect how environments are subscribed
Production / non-production	May affect entitlement requirements
Cloud location	Can change the commercial model
Subscription status	Establishes available entitlement
Contract terms	Defines what the organisation has purchased

This is where SAM becomes much more than software discovery.

The objective is not simply to discover that Red Hat Enterprise Linux exists.

The objective is to understand the relationship between:

deployment → product → metric → entitlement → contract → commercial exposure

Why traditional SAM approaches can struggle

Traditional SAM programmes have often been designed around relatively straightforward questions:

How many installations do we have?

How many subscriptions have we purchased?

Do the two numbers match?

That approach can work reasonably well for certain software products.

It becomes much more challenging when the commercial model is influenced by infrastructure architecture.

Enterprise Linux environments can contain:

• Physical servers

• Virtual machines

• Hypervisors

• Private clouds

• Public clouds

• Kubernetes clusters

• Container platforms

• Development environments

• Disaster recovery environments

• High-availability configurations

• Shared infrastructure

The SAM practitioner therefore needs to understand not only software licensing, but also the architecture supporting that software.

This creates a natural intersection between SAM, ITAM, cloud management and infrastructure architecture.

The data problem

Another challenge is data.

Many organisations already have extensive technology data available through tools such as CMDBs, discovery platforms, cloud management platforms, configuration management databases and vendor-specific tools.

But having data is not the same as having an Effective License Position.

A SAM programme needs to transform technical data into commercially meaningful information.

For an enterprise Linux environment, this could involve a process such as:

Collect → Normalise → Identify → Map → Analyse → Reconcile → Optimise

1. Collect

Gather relevant information from existing customer systems.

This might include operating system information, infrastructure characteristics, virtualisation data, cloud information and subscription records.

2. Normalise

Technology data rarely arrives in a consistent format.

Different tools may identify the same product in different ways.

Normalisation creates a common software and infrastructure data model.

3. Identify

Determine exactly what products and versions are present.

This is particularly important where multiple generations or related products exist within the same technology estate.

4. Map

Map deployments against the relevant commercial products and metrics.

This is where technical understanding and licensing expertise need to come together.

5. Analyse

Compare the deployment position with the available entitlement and contractual position.

6. Reconcile

Identify gaps, excess subscriptions, incomplete data and areas requiring further investigation.

7. Optimise

The final objective shouldn't simply be compliance.

Organisations should also look for opportunities to:

• Remove unused subscriptions

• Reallocate entitlements

• Improve subscription utilisation

• Identify unsupported environments

• Reduce unnecessary spend

• Improve data quality

• Prepare for vendor negotiations

• Reduce audit exposure

SAM for open source is not about policing developers

This is an important distinction.

The objective isn't to discourage the use of open-source technology.

Quite the opposite.

Open source is fundamental to modern technology environments.

Linux, Kubernetes, container technologies, automation platforms, databases, programming languages and thousands of open-source components underpin today's enterprise infrastructure.

The role of SAM is to help organisations understand the commercial and operational implications of how that technology is being consumed.

Good SAM should enable technology adoption, not obstruct it.

Where Red Hat and SUSE fit into the conversation

Enterprise vendors such as Red Hat and SUSE demonstrate why open-source software deserves a place within a mature SAM programme.

Organisations can have substantial investments in these ecosystems while simultaneously operating complex infrastructure environments.

The challenge is therefore not:

"Do we use open source?"

The better question is:

"Do we understand how our use of open-source technology translates into commercial subscriptions, contractual obligations, operational risk and optimisation opportunities?"

That is a much more useful SAM question.

The opportunity for modern SAM

The traditional SAM market has spent years focusing on a relatively small group of major proprietary software publishers.

That focus made sense.

But enterprise technology has changed.

Modern IT estates increasingly contain:

• Open-source technologies

• Subscription-based software

• Cloud platforms

• Containers

• Kubernetes

• Infrastructure as Code

• SaaS

• Platform engineering

• AI and machine learning platforms

The boundaries between software, infrastructure and cloud are becoming increasingly blurred.

SAM needs to evolve with them.

From licence management to technology consumption management

The future of SAM is unlikely to be simply about counting licenses.

It is about understanding how technology is consumed.

That means connecting:

Technology data

with

Commercial entitlements

and

Contractual rights

to produce

Business decisions

For open-source software, this approach can provide organisations with greater visibility into their technology estate, commercial commitments and optimisation opportunities.

Open source may be freely available.

But the enterprise environment built around it still needs to be managed.

Open source doesn't mean no asset management.

It means SAM needs to evolve.