Seven Years of ODPS: From Open Specification to Industry Reference

In 2019, ODPS almost became a hidden feature inside one proprietary platform, but instead it became public and open source. Seven years later, that decision has grown into much more than one specification: ODPS became a Linux Foundation project, moved through several public versions, expanded into a standards family, gained an SDK, added AI-agent-ready sidecars, and became the foundation for five Udemy masterclasses. This post tells the story from my perspective as the igniter and maintainer, not as a simple product story, but as a real example of what standard development takes: persistence, rewrites, governance, tooling, teaching, public feedback, and the Finnish idea of sisu. It also asks a fair question: did it make any sense? My answer is yes, because the data product problem has only become more important. Organizations need more than data catalogs and metadata fields. They need a shared, machine-readable, business-ready way to define data products so that people, platforms, governance models, and AI agents can work with them.

What it takes to build an open standard, and why sisu matters

In 2019, I was working as Chief Development Officer in a construction business focused platform company. That is where the idea behind the Open Data Product Specification, ODPS, began. The problem was practical. We needed a better way to describe data as a product, not only as data, an API, a file, a dataset, or a technical asset. A data product needed a clearer shape. It needed an owner, a user, a purpose, access rules, quality rules, support, and a business reason.

The first version of the idea started inside a proprietary platform. That detail matters because ODPS was close to never becoming an open standard. It could have stayed as an internal model, useful inside one company, one platform, and one business context. That would have been the normal path. Many useful ideas stay locked inside products because they are treated as platform features rather than as shared market needs.

I saw the problem differently. The need was bigger than one platform. Data products needed a shared way to describe what they are. That structure had to work across tools, platforms, catalogs, marketplaces, governance models, and later AI agents. I raised the idea with the CEO and suggested that we make it public and open source. He agreed, and that decision changed the path. I moved the work toward an open model under opendataproducts.org. What could have stayed as one platform feature became the start of an open standard. I started driving ODPS forward on my own time.

That early decision still matters. Data product definitions should not be trapped inside one vendor model. They should be portable, machine-readable, and usable across many organizations and platforms. ODPS did not become open because openness was the easiest route. It became open because the problem itself needed openness. And one goofy enough person to make the move.

The practical problem behind ODPS

Most organizations already had metadata. That was not the real gap. The real gap was product thinking. A product is more than an asset. A product has a user, a value promise, access rules, support, a lifecycle, and a reason to exist. Data work often focused on systems, schemas, lineage, and governance controls, but those things did not answer basic product questions well enough.

The questions were simple, but they were often missing from the structure. Who is this for? What problem does it solve? Who owns it? How do users access it? What quality level should users expect? What happens when it fails? How does it support a business goal? ODPS grew from the need to make those answers clear, structured, and reusable.

The work continued through 2020 and 2021. The first open-standard GitHub commit came on December 2, 2021. ODPS 1.0 was published on February 4, 2022. The Open Data Product Initiative was established in July 2022 to give the work a more stable home and to support growth beyond one person, one company, or one platform.

I have lived and breathed ODPS for seven years now. From the outside, the work may look like versions, GitHub repositories, diagrams, articles, SDK commands, and courses. From the inside, it has been years of writing, rewriting, testing, explaining, teaching, and refining the same core idea: data products need an open, structured, business-ready foundation.

Making the first version visible

ODPS 1.0 was the first public production release. It described data products through technical, business, legal, and ethical aspects. It was not a final answer, and no first version of a standard should pretend to be. Its value was that people could see the idea, test it, question it, and improve it. That changed the discussion from an abstract debate into something more practical.

This is one of the first lessons from standard development. A standard cannot live only as an idea. It needs a visible form. People need something they can read, use, reject, or improve. A strategy deck does not create adoption. A concept does not create alignment. A public model creates a starting point that others can react to.

Publishing a first version also requires courage. Once the model is public, people can point at weak parts. They can challenge names, structure, scope, and assumptions. That can be uncomfortable, but it is necessary. A standard that cannot survive feedback will not survive implementation.

Making ODPS easier to use

ODPS 2.0 came in April 2023. It moved the model toward a standalone data product description. This was important because a data product should not depend on one catalog, one marketplace, or one platform. A data product definition should move across systems and still keep its meaning.

ODPS 2.1 came in August 2023. It added JSON Schema and real-world examples, which made the standard easier to test and easier to understand. A specification without validation leaves too much room for interpretation. A specification with examples gives users a path from reading the standard to applying it.

This phase taught me that a standard does not mature only by adding fields. It matures through usability. Examples, validation, naming clarity, field structure, documentation, and implementation guidance reduce the cost of adoption. If every user needs a meeting with the maintainer before they understand how to use the standard, the standard is not mature enough.

Governance, YAML, and Linux Foundation

Late 2023 was an important turning point. ODPS started to move toward stronger governance and better release discipline. Release processes were formalized, and the move from JSON examples to YAML was announced. The work started to look less like an evolving idea and more like an open standard with review cycles, controlled releases, and clearer maintainership.

The YAML shift mattered because data product files are read by people, not only machines. Product owners, architects, governance teams, platform teams, and AI-assisted workflows need files that are easy to read and edit. This was not only a format change. It was a usability choice that made the standard more approachable in daily work.

In May 2024, ODPS became a Linux Foundation project. ODPS 3.0 followed later in May 2024 as the first YAML-first production release. It also moved ODPS toward “Everything as Code” for SLA and data quality.

This changed the weight of the work. An open standard needs more than ideas. It needs process, releases, review, maintainers, issue handling, and trust. Creating something alone is easier than maintaining something openly, because open work needs patience, transparency, and the ability to accept that the fastest next step is not always the right next step.

Moving to Abu Dhabi and seeing the scale problem

In November 2022, I moved to Abu Dhabi, UAE. That move changed how I saw ODPS. It was no longer only an idea that had grown from platform work in Finland. It became part of a wider professional journey in government data, open data, data products, and later AI-ready metadata.

Abu Dhabi gave the work a scale lens. Government data work brings many entities, domains, systems, rules, users, and value goals together. In that setting, unclear language becomes a real problem. When the number of datasets, stakeholders, and use cases grows, vague terms slow everything down. It becomes harder to know what exists, who owns it, what it supports, how it connects to goals, what quality it has, and whether it is ready for platforms or AI agents.

That context reinforced the original ODPS direction. The world did not need another slogan about treating data as a product. It needed practical structures for making data products real across organizations, platforms, governance models, and business objectives.

Sisu: the Finnish word behind the work

There is one Finnish word that fits the ODPS journey: sisu. It is difficult to translate with one English word, but it means persistence, courage, endurance, and inner strength when the work is hard and progress is slow. It is not loud confidence or public enthusiasm. It is the quiet ability to continue when the result is not clear yet, the feedback is uneven, and stopping would be easier than continuing.

Standard development requires exactly that kind of persistence. It is not a short campaign or a launch event. It is years of writing, testing, explaining, listening, fixing, teaching, and improving. Much of the work is invisible from the outside. People see release notes, diagrams, GitHub repositories, SDK commands, and course pages, but they do not see the long work behind naming one object well, deciding which concern belongs in which specification, rewriting examples, testing structure, or explaining the same idea to a new audience.

Standards grow through pressure. The first version is never enough, adoption is not automatic, and feedback is not always easy to receive. The market does not move at the same speed as the idea. That is why sisu matters in this story. ODPS has grown because the same practical problem kept proving itself important: data products need a shared, machine-readable, business-ready structure before they can scale across platforms, organizations, governance models, and AI agents.

Sisu in standard development means staying with the work long enough for an idea to become structure, the structure to become usable, and the usable structure to become shared practice.

ODPS 4.0: modular and monetization-ready

By 2025, the specification needed to handle more serious product structures. ODPS 4.0 introduced modular reuse through references, especially around SLA, data quality, access, and payment gateways. It also strengthened monetization structures and made the model more suitable for complex product environments.

This was important because real data products rarely stay simple. One organization may need shared quality rules across many products. Another may need reusable access patterns. Another may need common pricing structures. Another may need licensing and payment logic that stays consistent across many products. Without modularity, specifications become repetitive, and repetition creates maintenance risk.

If the same logic must be copied into many places, it will drift. Modular references help teams manage product definitions at scale. At this point, ODPS started to feel less like a single document model and more like part of a data product operating model.

ODPS 4.1: linking products to outcomes

ODPS 4.1 made the link between data products and business outcomes more explicit through productStrategy, objectives, product KPIs, and business KPIs.

This matters because many data product discussions still stop too early. A team may define ownership, access, and quality, but the business reason remains vague. A product should not exist only because data exists. It should support a use case, a decision, a workflow, a customer need, a risk reduction goal, or a revenue opportunity.

The productStrategy direction made ODPS more aligned with business leadership. It allowed the specification to say that a data product is not only governed and technically described, but connected to measurable outcomes. That is where data product management becomes more serious, because without a value link, a team is managing an asset and hoping value appears later.

Why one specification became a family

By 2026, it was clear that ODPS should not keep absorbing every adjacent concern. A single specification needs focus. ODPS should describe one data product well. If it also tries to describe catalogs, portfolios, graphs, vocabulary, workflows, recipes, and agent context, it becomes too heavy.

The solution was separation of concerns. ODPS remains the specification for one data product. ODPC adds the catalog and portfolio layer. ODPG adds the graph and relationship layer. ODPV adds the shared vocabulary layer. ODPR adds the workflow recipe layer. The Open Data Products SDK becomes the execution layer across the family.

This family direction was publicly announced in release-candidate form in May 2026. The artifact map describes the shift from one specification into a family where ODPS defines one product, ODPC organizes portfolio objects, ODPG connects relationships, ODPV keeps language aligned, and ODPR describes repeatable delivery workflows.

This is an important lesson from standard development. Expansion should not mean putting every new need into the original specification. Healthy expansion creates clear boundaries. Each artifact should have a job, and each job should be easy to explain. ODPS describes the product, ODPC organizes the portfolio, ODPG shows relationships, ODPV aligns the language, ODPR describes workflows, and the SDK makes the work executable.

The SDK: from specification to operating practice

The Open Data Products SDK changed the nature of the work again. Specifications define structure, but tools make that structure usable in daily work. The SDK provides capabilities across the standards family, including detection, loading, validation, explanation, summarization, reference resolution, portfolio workflows, LLM-assisted generation, CLI commands, and a local MCP server. It is not only an ODPS YAML validator. It is a practical interface for working across ODPS, ODPC, ODPG, ODPV, and ODPR.

This matters because standards adoption often fails at the point of effort. People may agree with the idea, but they still need to create files, validate them, convert input documents, generate examples, manage catalogs, build graphs, and check relationships. The SDK reduces the distance between concept and use by helping teams apply, test, and automate the ODPS family.

It also changes the role of AI. With the SDK, normal documents, notes, requirements, and source materials can become structured data product artifacts. That is important because most data product work does not begin in a perfect schema. It begins in business language, workshops, strategy documents, governance notes, spreadsheets, and scattered requirements. The SDK helps bridge that gap.

Sidecars and AI-agent context

As AI agents became more relevant, another problem became clear. Agents need context, but context has cost. Long YAML files can be useful, but agent workflows often need compact, task-focused representations. That is where TOON, GCF, and OKF fit into the ecosystem.

TOON and GCF were introduced as compact representations for agent-facing graph and portfolio context. GCF is optimized for graph-shaped content. OKF adds a readable Markdown-based knowledge layer beside the structured truth. These sidecars do not replace ODPS, ODPC, ODPG, or ODPV as canonical sources. They are derived formats for human review and agent use.

This distinction matters. A standard family needs canonical truth, but it also needs delivery formats. Humans, validators, catalogs, graphs, and AI agents do not always need the same representation of the same knowledge. Canonical YAML gives structure, schemas give validation, graphs give relationships, sidecars give compact context, and knowledge formats give readability. The SDK connects these needs into practical workflows.

The learning layer: making the work teachable

Alongside the specifications and SDK, I created five Udemy masterclasses. I did this because a standard does not spread only through repositories, schemas, and release notes. It spreads when people understand why it exists, how to apply it, and how it connects to their real work.

The learning layer has become part of the ODPS ecosystem in practice. The artifact map places courses and masterclasses alongside the specification family, SDK, knowledge base, and exercises as applied assets around the standards work.

The five Udemy masterclasses cover different parts of the journey.

• The Data Product MasterClass focuses on the business foundation and the shift from raw data thinking to product thinking.
• The Data Product Monetization MasterClass focuses on value, pricing, monetization, and the commercial logic around data products.
• The Minimum Lovable Governance MasterClass focuses on lightweight governance that supports trusted, scalable, and business-ready data products.
• The Master the Leading Data Product Specification with GPT Tool course focuses on hands-on ODPS usage and turning product ideas into machine-readable YAML.
• The Scalable Data Product Value Management with Agent-ready SDK course focuses on the wider ODPS family, product catalogs, value graphs, SDK validation, and agent-ready workflows.

This learning path matters because many people agree with the phrase “data product,” but still struggle to make it operational. The courses help translate the standards into work. They give people a path from theory to practice without waiting for a full platform implementation.

For those who want to support the ongoing ODPS work, one practical way is to take one of the Udemy masterclasses. The courses are available through my Udemy instructor profile: https://www.udemy.com/user/jarkko-moilanen/

That support also creates a useful feedback loop. Teaching exposes unclear concepts. Student questions reveal where the specification, examples, SDK, and documentation need to improve. A good learning layer does not only distribute the standard. It improves the standard.

What standard development really looks like

From the outside, standard development may look like version numbers, diagrams, repositories, and announcements. From the inside, it is more repetitive and demanding. You write the first version, find gaps, rewrite, explain, receive feedback, adjust names, create examples, fix schema details, improve documentation, revisit assumptions, remove confusing parts, split concerns, create tooling, teach, and explain again.

The work moves forward through small decisions that accumulate over years. There are moments of visibility, such as a public release, Linux Foundation onboarding, a new SDK version, or a standards family announcement. There are also many quiet moments where the work is simply maintenance: improving wording, checking examples, refining the model, preparing releases, updating knowledge base material, building training exercises, and making sure the whole system still makes sense.

This is where sisu becomes more than a cultural reference. It describes the kind of persistence required when the reward is not immediate and the work still needs to continue. In standards work, sisu is the decision to keep improving the structure when it would be easier to stop at the slogan.

Why ODPS still matters

The world has moved closer to the original ODPS problem. Data products are no longer only a data management topic. They now sit inside data mesh, governance, open data, data marketplaces, AI readiness, agentic workflows, and business value management.

The rise of AI agents makes the problem even sharper. Agents cannot rely on vague catalog descriptions. They need structured context. They need to know what a product is, who owns it, what it supports, how it can be accessed, what quality expectations it has, how it connects to objectives, what policies apply, and what workflows can be executed around it. Humans can tolerate ambiguity longer than machines can. AI agents expose weak metadata fast.

This makes the ODPS family more relevant now than when the idea started. ODPS gives the product definition. ODPC gives the portfolio layer. ODPG gives the relationship layer. ODPV gives the shared vocabulary. ODPR gives workflow structure. The SDK gives the practical interface. Sidecars give agent-ready context. The courses help people learn how to use the whole system.

What ODPS has taught me

ODPS has taught me that a standard is not only a technical artifact. It is a long-term negotiation between vision and usability. If the vision is too weak, the standard becomes another metadata template. If the usability is too weak, the standard becomes an elegant document that nobody applies.

The hard part is keeping both alive. ODPS must stay business-focused and practical. It must support real implementation without losing the bigger idea. It must serve technical teams without becoming only technical. It must serve governance teams without becoming only governance. It must support AI agents without forgetting human product owners.

The artifact map describes the strongest analytical takeaway well: ODPS did not simply grow features. It changed operating level several times. It moved from a single product-definition standard, to a governed and automatable model, to a family of catalogs, graphs, vocabulary, and workflows, and finally into an implementation surface through the SDK, sidecars, recipes, and training material.

Did it make any sense?

After seven years, this is the honest question. Did it make sense to spend so much time on a specification family for data products? Did it make sense to write, rewrite, publish, explain, maintain, teach, and build tooling around something that started as a practical gap in platform work?

My answer is yes, but not because ODPS is done. It made sense because the original problem has become more visible every year. Organizations now talk about data products more than they did in 2019. Data mesh, data marketplaces, open data platforms, governance modernization, AI readiness, and agentic workflows have all pushed the same issue forward: data needs a product structure that goes beyond technical metadata.

The work also did not stay as one document. ODPS became a governed specification. It moved under the Linux Foundation. It evolved through public versions. It expanded into a standards family. It gained an SDK. It gained sidecars for AI-agent context. It gained a knowledge base, examples, exercises, and five Udemy masterclasses. The artifact map shows this shift from one specification into a family covering product definitions, catalogs, graphs, vocabulary, workflows, SDK tooling, sidecars, training material, and applied examples.

https://opendataproducts.org/

The strongest signal is that the work has started to matter outside my own writing and courses. Companies with real scale, including BASF and Alation, have built foundations on top of ODPS. Alation’s AI-ready data product work appears in the ODPS timeline as a meaningful external validation milestone, which matters because standards become real when others decide to build on them.

A standard is not validated by the maintainer believing in it. It is validated when organizations with their own priorities, platforms, customers, and constraints decide that the structure is useful enough to build on. That does not mean the work is finished. It means the direction has survived contact with reality.

For me, that is the real test. A standard idea only matters if it stays useful after the first excitement fades. ODPS has kept growing because the need has kept growing. Data product teams still need structure. Platform teams still need interoperability. Governance teams still need clarity. Business leaders still need value links. AI agents now need context that is structured enough to use.

The work ahead

ODPS still needs more adoption, more examples, more feedback, more integrations, more tested workflows, and more people applying it in real organizations. The family will need to mature. The SDK will need to keep improving. The knowledge base will need more practical guidance. The courses will need updates as the standards evolve.

That is normal for open standards. They are living agreements that improve through use. The next phase is about making the ODPS family easier to apply in everyday data product work. That means better onboarding, clearer templates, more SDK workflows, stronger graph examples, more practical governance patterns, and more AI-agent-ready context. It also means continuing to explain why data products need structure before they can scale.

The motivation remains the same. Data products need an open, structured, business-ready foundation. Without that foundation, organizations will keep renaming data assets as products without changing how value, ownership, governance, and usability work.

ODPS is my contribution to solving that problem. It started from construction business platform work in 2019. It moved through rewrites, public releases, governance, Linux Foundation onboarding, YAML, Everything as Code, modularization, outcome alignment, a standards family, an SDK, sidecars, workflow recipes, and a learning path.

Seven years later, I still see the same need more clearly than before. Data products need more than language. They need structure, standards, tools, and people who understand how to apply them.