• Skip to primary navigation
  • Skip to main content
  • Skip to footer

Codemotion Magazine

We code the future. Together

  • Discover
    • Events
    • Community
    • Partners
    • Become a partner
    • Hackathons
  • Magazine
    • Backend
    • Frontend
    • AI/ML
    • DevOps
    • Dev Life
    • Soft Skills
    • Infographics
  • Talent
    • Discover Talent
    • Jobs
    • Manifesto
  • Companies
  • For Business
    • EN
    • IT
    • ES
  • Sign in
ads

Marco IannaconeAugust 27, 2026 11 min read

AI Needs Open Source Governance

AI/ML
facebooktwitterlinkedinreddit

Opening the model isn’t enough. The system built around it has to be verifiable.

I started my career in computing back when the internet wasn’t yet a set of platforms to spend time on, but an infrastructure to explore, understand, and help build. There were no video courses sold with a countdown timer, no tech influencers, no AI assistants confidently answering questions they knew nothing about. There was technical documentation, mailing lists, newsgroups, FAQs, repositories, and people who freely shared what they’d learned.

Recommended article
August 27, 2026

The end of the prompt era: why the future of AI development belongs to those who write specs (SDD)

Matteo Baccan

Matteo Baccan

AI/ML

Being largely self-taught, that shared knowledge didn’t just expand my skills — it shaped my professional identity. Over the years I tried to give something back: writing guides on the internet and virtual reality when both still felt like frontier territory, maintaining Linux FAQs, contributing to open source projects, doing tech journalism. For a while I was even what people back then unironically called an open source “evangelist.”

Looking back now brings a certain nostalgia — not for noisy modems or hand-compiled configs, but for the idea that technical knowledge could be a shared good: something everyone received, improved, and put back into circulation. That idea wasn’t just generous. It was one of the mechanisms that made innovation possible.

This piece traces a path from the open internet I grew up on, through the closed algorithms of big platforms, to today’s open-weight AI models. From there I want to shift the question: not just how open a model is, but how verifiable the system built around it is. I’ll use AI in education and a framework called L×M×C as a concrete case study, then land on a broader proposal for open source governance of AI systems.

An open network, governed by closed algorithms

The internet grew on public protocols, interoperable standards, open software, and distributed communities. Nobody needed permission from a central owner to build a new service on HTTP, TCP/IP, SMTP, or DNS — not just the protocol but the software implementing it was open too.

Openness didn’t eliminate conflict or dominant players, but it prevented any single organization from unilaterally deciding how the whole network should evolve.

Something different happened with the rise of big social platforms. The technical foundations of the network stayed largely open, while the systems deciding what to show people, what to amplify, what relationships to suggest, and what behavior to reward became proprietary, opaque, and constantly changing. A network built on open protocols ended up governed by closed decision-making systems — systems that weren’t just organizing information but shaping the cognitive and social environment where millions of people spend a growing share of their day.

Cambridge Analytica made part of this visible to the public: not simply a consequence of closed code, but proof that personal data, profiling systems, ad architectures, and opaque platform logic could be combined to influence politics and society at scale.

Since then, evidence has piled up on the harm certain social media patterns cause young people. The U.S. Surgeon General has cited data showing teens who spend more than three hours a day on social media face roughly double the risk of mental health problems, with more recent studies pointing to serious effects on anxiety, depression, and wellbeing — especially among girls.

The issue has moved beyond research. In 2026, U.S. juries found Meta and Google/YouTube liable in cases over child protection, recognizing responsibility tied to design features like infinite scroll, autoplay, notifications, and recommendation algorithms.

We’ve already seen what happens when opaque algorithmic systems get optimized to maximize engagement among millions of kids. With AI — even more pervasive, and capable of interacting with them directly — repeating that experiment would be unwise.

EU lawmakers have started targeting architecture, not just content. The Digital Services Act requires platforms accessible to minors to protect their wellbeing, privacy, and safety, and bans targeted advertising to children. In July 2025 the European Commission published specific guidelines on child protection covering recommendation systems and platform design.

The point isn’t that closed algorithms are inherently harmful and open ones automatically ethical — that would be reassuring, simple, and false. The point is that for years we’ve let systems designed to maximize attention and engagement shape children’s behavior without making it publicly verifiable what benefit they produced, what risks they carried, or what metrics actually drove their evolution.

With machine learning, code isn’t enough anymore

In traditional software, source code is a fairly direct description of how a program behaves — not necessarily simple, but the instructions are at least available.

With machine learning, that correspondence weakens. Behavior no longer depends only on code, but on training data, model architecture, training procedures, learned weights, data selection criteria, fine-tuning, evaluation metrics, and countless decisions made during development.

With large language models it gets even more layered — behavior can depend on pretraining data and procedures, model architecture and weights, system instructions, alignment techniques, moderation filters, external tools the model can access, orchestration logic, evaluation criteria, and ongoing updates from the provider.

Publishing the application code that calls the model only exposes a fraction of the system. It’s like releasing a car’s dashboard and calling that documentation of the engine, transmission, and control systems. Open-sourcing the source code alone is no longer sufficient.

Open weights isn’t always open source

The rise of “open weight” models has added confusion. Releasing a model’s weights matters — it lets people run it on their own infrastructure, analyze it, fine-tune it, build on it without depending on a vendor’s API.

But being able to download the weights doesn’t mean you can understand how the model was built. The training data, selection criteria, training code, alignment procedures, and evaluation results may all be missing, and licenses often add usage restrictions.

The Open Source Initiative tackled this with the Open Source AI Definition 1.0: a system counts as open source only when it guarantees freedom to use, study, modify, and share it — which requires access to the actual form used to make changes to the system. Weight availability can be part of openness, but isn’t sufficient alone.

A concrete comparison helps. Meta’s Llama releases weights but not training code or pretraining data, and its license restricts use above 700 million monthly active users — a condition the Open Source AI Definition explicitly excludes from its first freedom. OLMo 3, from the Allen Institute for AI, takes a different approach: weights, full training code, intermediate checkpoints, and the roughly 6-trillion-token Dolma 3 pretraining dataset are all released under Apache 2.0. With Llama, an independent researcher can run the model but not reproduce it or verify how it was built. With OLMo, they can do both.

The contradiction is sharper when you look at today’s most competitive open-weight models. Moonshot AI’s Kimi, Z.ai’s GLM, and Alibaba’s Qwen have nearly closed the gap with proprietary models on coding and reasoning in 2026. They’re freely available, but none systematically publishes training code and data details in the form OSAID requires — while OLMo, which actually meets those requirements, remains a niche product. The ecosystem seems to reward “free as in beer” far more than “free as in speech.”

Opening the model isn’t enough to open the system

Even a genuinely open source model doesn’t guarantee the application built on top of it is transparent, safe, or aligned with users’ interests.

An AI system is the result of many layers: the base model; the data and procedures used to adapt it; the instructions shaping its behavior; the application it’s embedded in; the goals assigned to it; the metrics it’s judged by; the processes for catching errors and consequences; and the governance deciding changes, priorities, and trade-offs.

An open model can sit inside a system optimizing entirely opaque criteria. Conversely, a proprietary model can power an application that clearly states its goals, constraints, metrics, and evaluation results. Openness has to cover the whole sociotechnical system, not just one component.

This is where open source meets governance. It’s no longer enough to ask “can I see the code?” We also need to ask: What is the system optimizing for? Who chose that objective? What data and metrics measure it? What downsides were considered? Who can verify results? Who can challenge design choices? How are changes managed? What happens when user interest conflicts with provider interest?

These questions matter even more in healthcare, employment, credit, justice, and education.

When the algorithm enters the classroom

Schools are where the gap between “performance” and “benefit” becomes most visible.

A generative AI system can be very effective at giving correct answers, summarizing text, solving problems, or producing polished writing. But education’s goal isn’t just a correct output. A student can hand in an excellent answer without having developed any understanding — getting the cognitive product without going through the process that should have generated it.

That’s not a side effect. It follows directly from the objective most general-purpose AI is designed around: be helpful, answer fast, minimize effort. In professional work that drives productivity. In learning, systematically removing effort can remove the very mechanism through which understanding, autonomy, and the ability to transfer knowledge get built.

So the real question isn’t just which model to use in schools. It’s: what idea of learning is embedded in the system? If that idea stays implicit and proprietary, teachers, families, and institutions can only judge the surface — ease of use, response speed, interface polish, maybe factual accuracy. They can’t verify what the system is actually optimizing for cognitively.

An open framework for contestable educational AI

This is the problem behind L×M×C, a framework I developed as the theoretical foundation for Proxima ZSP, an AI-based Socratic tutoring system. The framework, manifesto, and academic preprint are published openly under CC BY 4.0 at lmc.proxima-zsp.it.

Rather than judging interaction quality purely on the correctness of the final answer, the framework considers three dimensions: depth of reasoning; metacognition — the student’s ability to observe and regulate their own thinking; and consolidation — whether what’s learned can be stabilized and transferred. Proxima ZSP’s goal isn’t to answer for the student, but to intervene through questions, requests for explanation, and reformulations that help students build their own path to a solution.

The point here isn’t that this framework is the definitive answer — that claim would sit awkwardly with the whole logic of openness. The point is that it’s public, criticizable, and changeable. A teacher can challenge how reasoning depth is defined. A researcher can propose better metrics. A developer can build a different implementation. A school can decide some criteria don’t fit its students.

Openness doesn’t guarantee the framework is correct. It guarantees something more important: nobody has to take its correctness on faith. In my own case, this openness already had a concrete consequence — analyzing the metacognition metric revealed it conflated spontaneous reflection with the ability to reflect when prompted, so I’m now respecifying it before the controlled trial begins. That’s exactly the kind of process that should apply to every AI system: surface the problems, fix the metrics that don’t work, let others verify them.

From the right to see the code to the right to understand the system

Algorithmic transparency is often treated as a technical matter: documentation, audits, code access, explainability. But real transparency starts with an earlier question: what benefit does the system claim to produce?

For any algorithmic system aimed at minors, at minimum the following should be public: the expected benefit; the intended population; the metrics used to measure that benefit; available empirical evidence; foreseeable risks; potentially vulnerable groups; independent evaluation results; how the system gets updated; and mechanisms for educators, families, and researchers to challenge how it works.

It shouldn’t be enough to show a technology doesn’t formally break a rule. Anyone putting a system into children’s lives should have to state what benefit they intend to produce and show how they’ll measure it over time.

The EU AI Act already requires transparency, risk management, and documentation for certain high-risk categories. The Digital Services Act requires large platforms to assess and mitigate systemic risks, including those affecting minors. These are important steps, but the conversation needs to expand from “avoiding demonstrable harm” to “demonstrable benefit.” Between not causing obvious harm and producing real benefit lies a huge space — and that’s exactly where a lot of educational technology operates today.

Open source governance as public infrastructure

Open source governance for AI doesn’t mean forcing every company to indiscriminately publish data, trade secrets, and IP. It means building systems where objectives, evaluation criteria, limits, and decision-making processes can be scrutinized — letting the community participate not just in writing the software, but in defining what the software should do.

We’re not starting from zero. Model Cards, proposed in 2019, standardize documentation of a model’s data, limits, and intended uses. The OSI’s Open Source AI Definition, mentioned earlier, does similar work. Stanford’s Foundation Model Transparency Index has scored major model developers on transparency since 2023 — and the 2025 results are telling: the average score dropped from 58 to 40 out of 100 in a single year, reversing prior gains. Meta fell from 60 to 31, Mistral from 55 to 18. Chinese companies, scored for the first time in 2025, landed in the bottom half. The tools to measure this already exist and are producing results — and industry transparency is getting worse, not better. The problem isn’t a lack of metrics. It’s that nobody is required to score well to keep operating.

Beyond that, we also need public evaluation protocols, benchmarks that measure more than raw performance, documented and verifiable datasets, independent audit tools, open specifications for high-impact systems, multidisciplinary communities involving developers, researchers, educators, lawyers and users, and governance mechanisms that surface conflicts of interest and decisions.

The open source community doesn’t need to train the next hundred-billion-parameter foundation model in a garage — that garage would need an unusual amount of GPUs, energy, and capital. But it can open up the layer where models get turned into social, educational, and decision-making systems. It can build tools to verify what these systems claim to do. It can define alternative metrics to the ones vendors choose. It can build implementations that aren’t subordinate to engagement maximization, data harvesting, or single-platform lock-in. Above all, it can stop technical complexity from being used as an excuse to keep decisions out of public reach.

Opening what exercises power

Open source was born from the idea that anyone using a program should be able to study, modify, and share it. Today, software doesn’t just execute requests — it selects information, predicts behavior, steers decisions, personalizes environments, and mediates a growing share of our experience of reality. So opening the code isn’t enough anymore. When a system exercises power over people, we need to understand what goals it pursues, what assumptions it embeds, how it’s evaluated, and who can change its behavior.

That’s why the L×M×C framework is open — not because it’s perfect, but so others can verify it, criticize it, adopt it, transform it, or show where it fails. It’s a genuine invitation to the technical, scientific, and educational community: the framework is published under CC BY 4.0 at lmc.proxima-zsp.it. Read it, stress-test it, find where it breaks. Build a different implementation, extend it to another domain or age group. Contributing to governance models where openness is a verifiable property rather than a marketing line starts with a link anyone can open today.

And it’s an invitation to lawmakers too: when an algorithmic system targets minors, make transparency mandatory not just about how it works, but about the benefit it claims to produce and the evidence backing that claim.

The internet showed that open infrastructure can generate innovation beyond what its creators imagined. AI poses a similar challenge now, with even bigger stakes. We shouldn’t just open up the technologies. We need to open up the decisions that turn those technologies into power.

Codemotion Collection Background
Dalla community
Our team’s picks

Want to find more articles like this? Check out the Dalla community collection, where you'll find a curated selection of fresh, new content just for you.

Share on:facebooktwitterlinkedinreddit

Tagged as:governance OpenSource

Marco Iannacone
The end of the prompt era: why the future of AI development belongs to those who write specs (SDD)
Previous Post

Footer

Discover

  • Events
  • Community
  • Partners
  • Become a partner
  • Hackathons

Magazine

  • Tech articles

Talent

  • Discover talent
  • Jobs

Companies

  • Discover companies

For Business

  • Codemotion for companies

About

  • About us
  • Become a contributor
  • Work with us
  • Contact us

Follow Us

© Copyright Codemotion srl Via Marsala, 29/H, 00185 Roma P.IVA 12392791005 | Privacy policy | Terms and conditions