Subject: CLEWs-EU is open: an EU27 integrated assesment model, and a webinar on 22 September

105 views
Skip to first unread message

Mark Howells

unread,
Sep 14, 2026, 12:11:30 PMSep 14
to Open Mod

Dear all,


A useful piece of open-modelling news to those into 'sub global' integrated assessment nexus modelling ... The OSeMOSYS-CLEWs family is now part of Türkiye’s in-house climate-policy modelling infrastructure as the country prepares to host COP31 [1] but more on that later ... In the meantime, the same modelling family now has a substantial European implementation which I wanted to draw attention to.


CLEWs-EU is now openly available, in both an aggregated EU27 version and a country-level disaggregated version. It brings energy, land and water into the same optimisation framework, rather than treating them as separate worlds. More importantly, this is not an empty framework waiting for someone to populate it. The repository contains the model, data files, supporting assumptions and data-preparation scripts, with detailed documentation of the underlying sources. Calibration draws on traceable European datasets including JRC-IDEES, Eurostat, ENTSO-E, European Commission assumptions and others. Where national land or water observations are missing, the documentation says so. [2][3]

The DIAMOND project is holding a webinar on Tuesday 22 September, 13:00–14:00 CEST to introduce the model. It is expressly aimed at people who might apply or extend it, and will cover the methodology, structure, documentation, code and data. If this is anywhere near your work, I would come. [2]


There is another reason to have a look. The OSeMOSYS/CLEWs world has become a rather pleasant place to pick up open-source integrated assessment modelling. There are free OpenLearn Create courses, dedicated OSeMOSYS and CLEWs channels on the Energy Modelling Community Discourse forum, public troubleshooting and live events. A newcomer can ask a basic question in the same space in which experienced modellers discuss changes to the formulation. There is less of an invisible threshold to cross before one is permitted to participate. [4]


And the mathematics can remain mathematics.

MOSOX (which we are adopting from the MOSAIC ecosystem) is not another modelling language: it is a Rust-based compiler for GMPL/MathProg, the algebraic language used by OSeMOSYS. GMPL lets equations stay close to their mathematical form, where they can be read, argued over and changed by people who are not software engineers - or AI agents. MOSOX keeps that property while making the machinery underneath considerably faster. In published OSeMOSYS benchmarks, it generated solver matrices up to 6.5 times faster than glpsol. The human-readable formulation remains in the loop; the tedious part gets quicker. [5]

There is also a useful development in the OSeMOSYS formulation for genuinely multi-resource systems. The current code can associate new or installed capacity directly with other commodities: steel embodied in new infrastructure, for example, or land occupied by existing capacity. The recent MUIO work also preprocesses these relationships so that irrelevant combinations do not inflate the problem. I will write separately about that, and about the Türkiye work. [6]

For now if you are in this space: please consider joining the CLEWs-EU webinar on 22 September. Download it. Run it. Question the assumptions. Break something useful. Put the result back into the commons. You know the gig ... 🙂


Best, Mark


References

  1. Türkiye climate-policy use of OSeMOSYS: CCG interview with Melih Fırat Ayaz, Türkiye Ministry of Environment, Urbanization and Climate Change; COP31-facing OSeMOSYS/CLEWs work: CCG COP31 support programme

  2. CLEWs-EU webinar, 22 September 2026, and description of the EU27 and national-detail models: DIAMOND — Introducing CLEWs-EU: A Nexus Model for Europe’s Energy, Land, and Water Futures

  3. Reproducible model materials and calibration/data sources: CLEWs-EU GitHub repository; CLEWs-EU user manual and model files; CLEWs-EU energy-module data and calibration documentation

  4. Learning and community support: Open University/OpenLearn Create Climate Compatible Growth courses; Energy Modelling Community forum and support channels

  5. MOSOX architecture and benchmarks: MOSOX preprint — fast model-to-matrix compiler for linear and mixed-integer optimisation; MOSOX source, benchmark scripts and documentation

  6. Multi-resource-capable OSeMOSYS relationships: MUIO documentation for InputToNewCapacityRatio and InputToTotalCapacityRatio; performance changes and preprocessing in MUIO v5.4 release notes


Mark Howells (Prof)

Director ClimateCompatibleGrowth.com see a quick video intro here

Joint Director STEER Centre, Loughborough University

Principal Research Fellow, Centre for Environmental Policy, Imperial College

Editor in Chief Energy Strategy Reviews

Google Scholar


Robbie Morrison

unread,
Sep 16, 2026, 12:03:47 PMSep 16
to openmod-i...@googlegroups.com

Hello Mark, DIAMOND project contributors, all

I checked the copyright and license notices in the six GitHub repositories that make up the DIAMOND project. I used this webpage headed "Open models" as the starting point for my investigations:

My analysis is summarized in the tables that appear near the end of this email.

Only one of the six projects that make up the DIAMOND project collectively passed my rudimentary open‑source license compliance tests. This exercise relied solely on the information contained within the respective GitHub repos. I did not check on upstream dependencies, nor the veracity of the copyright claims where present.

A license notice must include a copyright statement. Just adding unmodified license boilerplate to a code repository is legally meaningless. Note too that it is not especially important to keep the year of claim entirely current — such details will require alternative confirmation if civil litigation ever proceeds.

The CLEWs-EU repository — the only one to pass my cursory due diligence — last had activity on 26 November 2025. That is 293 days without anything happening. Could someone please confirm that this is where the development does occur and that this level of interaction is normal?

I readily concede that the term "open model" does not have a consensus definition. Projects should rather address the legal status of their codebases, databanks, solvers, and documentation separately and explicitly. The original openmod manifesto (listed in the reference section) covered these aspects individually too and should be considered a touchstone for this community. The five frameworks under discussion clearly fail to honor that early openmod manifesto — in which case, I question whether these frameworks should be promoted on openmod channels.

Turning attention to the new EU Cyber Resilience Act (CRA) which enters into full force during November 2027. The CRA contains the now familiar definition for open source at article 3(48) thus:

‘free and open-source software’ means software the source code of which is openly shared and which is made available under a free and open-source licence which provides for all rights to make it freely accessible, usable, modifiable and redistributable

If a software project makes its non‑legacy software available in Europe — as the six DIAMOND projects clearly do — and wishes to retain an exemption from CRA compliance under non‑profit open‑source provisions, that project will need an accurate copyright notice and a public software license that conforms with 3(48). That latter point essentially means OSI‑approved licenses. Five of the DIAMOND projects currently fail that double hurdle.

I therefore suggest that these five projects make urgent efforts to respect 3(48) copyright and licensing requirements or alternatively opt to comply with the full provisions of the CRA. There is no middle ground. And there is little more than 12 months to get these matters sorted. If the current status quo persists, the appropriate national CRA enforcement agency may well mandate compliance and possibly level penalties too.

Relicensing a software repository can be difficult and time‑consuming. Three of the cases under discussion lack OSI‑approved licenses. That means that all contributors with a potential copyright interest in the codebase must be contacted and must provide their consent to any new more permissive arrangements.

The REUSE project from the Free Software Foundation Europe (FSFE) offers good procedures and practices for open licensing public software (see references).

I recommend that funding agencies also seek to understand the effects of the CRA on science and policy projects that publish code.

Projects claiming to follow open science must live up to those ideals. The underlying principles are now well‑established, easily operationalized, and known to be legally sound. This is also becoming more important as public and civil society funders prioritize open development and legislators seek software safety.

with best wishes, Robbie

DIAMOND project models

  • a copyright notice and an OSI‑approved public license marks the project as "Open" subject to caveats
  • this investigation does not confirm that the copyright notice is correct
  • this investigation does not examine upstream dependencies to confirm their open‑source status
Project SPDX identifier OSI Copyright Open Repo Row
GCAM-Europe ECL-2.0 ✔ ✘ ✘ GitHub 1
OMNIA CC-BY-NC-SA-4.0 ✘ ✘ ✘ GitHub 2
CLEWs-EU MIT ✔ ✔ ✔ GitHub 3
GEMINI-E3 EU GLPL-2.1 ✔ ✘ ✘ GitHub 4
NEMESIS‑World Apache-2.0 + "Commons Clause" ✘ ✔ ✘ GitHub 5
OPEN-PROM AGPL-3.0 + "Commons Clause" ✘ ✘ ✘ GitHub 6
Project Row Copyright notice in full
CLEWs-EU 3 CLIMATE-DIAMOND (CLEWs-EU modelling team)
NEMESIS‑World 5 Baptiste Boitier (SEURECO), Pierre Le Mouël (SEURECO), Paul Zagamé (SEURECO), Hayat Mekki (SEURECO)

Source information

Table columns and rows explained

Col Comment
A the project name
B SPDX license identifier as per repo, noting that "Commons Clause" is not supported
C OSI means the license or license combination in use is approved by the Open Source Initiative for software
D Copyright indicates the GitHub repository contains a copyright notice
E Open merely indicates that a copyright notice and an OSI‑approved license is present
F link to associated code repository and specifically the License tab
G row counter
Row Comment
1 —
2 unclear if the XLSX spreadsheets contain VBA routines or not, but the NC attribute makes the data non‑open in any case
3 —
4 note typo on webpage which states "MIT License 2.0" but the "2.0" should be omitted
5 —
6 —

References

▢

--
You received this message because you are subscribed to the Google Groups "openmod initiative" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openmod-initiat...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/openmod-initiative/BR2PR04MB3636397CD8B53E2415713B661FF8BB2%40BR2PR04MB363639.eurprd04.prod.outlook.com.
-- 
Robbie Morrison
Address: Schillerstrasse 85, 10627 Berlin, Germany
Phone: +49.30.612-87617

Mark Howells

unread,
Sep 16, 2026, 2:13:45 PMSep 16
to openmod-i...@googlegroups.com
Dear Robbie,
Thanks for looking into this, but I think we are talking slightly past one another.
I am not promoting the DIAMOND project as a whole, nor was my email intended as an endorsement of the licensing arrangements of all six DIAMOND models. I have no particular brief for the other five here. My email was about CLEWs-EU, and more broadly about the CLEWs/OSeMOSYS ecosystem in which it sits.
That distinction matters.
CLEWs-EU is built in OSeMOSYS, and the surrounding ecosystem is hardly dependent on one DIAMOND GitHub repository. There is a fairly substantial body of openly available code, tooling, documentation and learning material around it.
For example:
  • OSeMOSYS itself is developed publicly on GitHub and its main repository contains the Apache-2.0 licensed implementations of the model in GNU MathProg, Pyomo, PuLP and GAMS. OSeMOSYS main repository
  • The wider OSeMOSYS GitHub organisation contains the core model and a considerable collection of related public repositories and tools. OSeMOSYS repositories
  • CLEWs has its own public repository, providing tools for Climate, Land, Energy and Water systems analysis under an MIT licence. CLEWs repository
  • There is also clewsy, the Python tooling for constructing CLEWs models using OSeMOSYS, again developed publicly. clewsy repository
  • The CLEWs_GAEZ / GeoCLEWs work provides open tooling for processing the land and water datasets used in CLEWs modelling. CLEWs_GAEZ repository
  • MUIO, the Modelling User Interface for OSeMOSYS, is another substantial public repository, with source, documentation, releases, an issue tracker and an Apache-2.0 licence. It is not some opaque executable being passed around behind closed doors. MUIO repository
  • And, yes, CLEWs-EU itself is publicly available, including the model development work, with an MIT licence. The repository explicitly says that development is intended to continue beyond the lifetime of DIAMOND. CLEWs-EU repository
There is then the learning side of this. The Open University/OpenLearn Create material includes a full Introduction to CLEWs course, currently listed as a 27-hour course, alongside OSeMOSYS teaching and more advanced CLEWs material. This is not simply a code dump: there is a deliberate attempt to make the modelling framework teachable and usable by people entering the field. Climate Compatible Growth OpenLearn Create courses
The current course collection includes Introduction to CLEWs, Advanced CLEWs/CLEWs++ modelling, and OSeMOSYS material. Individual CLEWs teaching worksheets are themselves published openly with explicit reuse licences; for example, the current CLEWs teaching material identifies its licence and points users towards the public Energy Modelling Community for discussion and troubleshooting.
So that is what I meant by the OSeMOSYS/CLEWs world being a rather pleasant place to pick up open-source integrated assessment modelling. I meant the code, the model formulations, the auxiliary tools, the teaching material, the documentation, the issue trackers and the community around them. There is quite a lot of open-source goodness there, and it exists well beyond the boundaries of DIAMOND.
Your audit of the other DIAMOND repositories may well raise questions worth putting to those projects. Fine. But they are not what I was promoting in my email.
On your specific question about why the CLEWs-EU repository itself has not seen a commit since November 2025, rather than speculate about where the team is currently developing and what their workflow is, I suggest you take up the invitation to the seminar on 22 September and ask them. That is exactly the sort of question the seminar is there for. The invitation was specifically to people who might use, scrutinise or extend the model, and explicitly encouraged people to download it, run it and question it.
You have clearly gone to some trouble to inspect the repositories, so it seems worth completing the exercise by asking the people actually developing CLEWs-EU how the repository is being maintained and where current development is taking place.
But I would not infer from issues you identify in five other DIAMOND repositories that there is therefore some corresponding lack of openness in OSeMOSYS/CLEWs. They are different propositions.
Meanwhile - for those who want a first open integrated assessment model for Europe and want to fork, built in a friendly open ecosystem - feel completely free (as in speech and beer 🙂) to do so ...
Best, Mark


From: openmod-i...@googlegroups.com <openmod-i...@googlegroups.com> on behalf of Robbie Morrison <robbie....@posteo.de>
Sent: 16 September 2026 17:03
To: openmod-i...@googlegroups.com <openmod-i...@googlegroups.com>
Subject: Re: [openmod-initiative] Subject: CLEWs-EU is open: an EU27 integrated assesment model, and a webinar on 22 September
 

** THIS MESSAGE ORIGINATED OUTSIDE LOUGHBOROUGH UNIVERSITY **

** Be wary of links or attachments, especially if the email is unsolicited or you don't recognise the sender's email address. **

Robbie Morrison

unread,
Sep 16, 2026, 2:25:07 PMSep 16
to openmod-i...@googlegroups.com

Hello Mark

Thanks.  Appreciate your reply.  Can you point me to the most recent commit for any of the OSeMOSYS variants?  I am interested because some of the related GitHub repositories do not seem to have much activity of late, as best I can tell.

kind regards, Robbie

Mark Howells

unread,
Sep 16, 2026, 2:55:01 PMSep 16
to Open Mod
Dear Robbie,
Yes - and I’d be a little careful about using the date on the top-level OSeMOSYS repository as a proxy for activity across the ecosystem.
There has been quite a lot going on recently across OSeMOSYS Global, MUIO and MOSOX, alongside the CLEWs work. The activity is spread across several repositories and tools rather than concentrated in one monolithic codebase.
More importantly, there is a fairly major advance working its way through testing at the moment. It allows multi-time-step resource tracking, which makes systems-of-systems modelling substantially more efficient - particularly where resources, infrastructure and other commodities need to be followed across interacting parts of the system rather than treated as isolated energy flows.
The team have been working on that over the summer. So hold tight on that one - I think you’ll love it when it lands.
And perhaps this is the more interesting point for the wider list. What we find exciting is that the OSeMOSYS/CLEWs ecosystem is making the modelling simultaneously more powerful, faster and easier for people to get into.
MOSOX is a particularly nice example. It keeps the formulation in GMPL/MathProg, so the equations remain very close to the mathematics and there is comparatively little syntax standing between the modeller and the actual formulation. That matters: a human can still read the equations, inspect them, challenge them and change them without having to work through a large amount of software scaffolding.
At the same time, MOSOX makes the model-to-matrix step much faster. The published OSeMOSYS examples show substantial speed-ups over glpsol, and in our testing we are also seeing it run faster than equivalent PuLP workflows. So we get an interesting combination: less syntax for the human to inspect, faster machinery underneath, and a formulation that remains intelligible enough to keep a genuine human in the loop. For anyone interested in the technical side, the MOSOX paper sets out the architecture and benchmarks.
That is also rather useful for AI-assisted modelling. An AI agent has less incidental software syntax to generate and manipulate, while the human can still see and interrogate the mathematical formulation it is working with. Happier humans; happier AI agents.
MUIO comes at the accessibility problem from another direction. It provides a graphical interface around OSeMOSYS, lowering the barrier to building, inspecting and working with models for people who should not first have to become expert programmers simply to participate. The MUIO documentation is also a useful starting point.
Then there is OSeMOSYS Global, which demonstrates the same open modelling approach at scale, alongside the CLEWs tooling, open training material, public documentation, forums and the growing collection of tools around the core formulation. Its documentation is here.
That combination matters to me much more than a leaderboard of GitHub commits: keep the mathematics visible, make the machinery faster, make the tools easier to use, and lower the barrier to participation.
So, for anyone else copied here who has been thinking about trying OSeMOSYS or CLEWs: please do. Have a look at MOSOX, MUIO and OSeMOSYS Global. Fork something. Try the CLEWs material. Take one of the courses. Join the community and ask an embarrassingly basic question — those are often the useful ones.
There is a lot happening, and plenty of room for more people to help shape where it goes next.
Best, Mark


Sent: 16 September 2026 19:24

Robbie Morrison

unread,
Sep 16, 2026, 4:26:56 PMSep 16
to openmod-i...@googlegroups.com

Hi Mark

Thanks. To take the first three repos you cite, that's 8 months, 4 months, and 5 months of inactivity. And 10, 4, and 1 contributors in total for each. Did I get that correct?

best, Robbie

Mark Howells

unread,
Sep 16, 2026, 6:59:54 PMSep 16
to openmod-i...@googlegroups.com
Dear Robbie,
Broadly, yes - although I have to say I find that a slightly curious way to respond to an invitation to download, inspect, use, challenge and contribute to an open modelling ecosystem. Perhaps this comes back to what openmod is for. I had understood its purpose to be to bring open models, tools, data and people together so that we can inspect them, question them, learn from them and improve them collectively. Scrutiny is part of that, of course - but so is participation.
You may well have the arithmetic right. But reducing the question to “months since last commit” and “number of contributors” seems to me to risk measuring what is easiest to count rather than what is most useful to know.
Perhaps quality over quantity is useful?
A repository does not become better because somebody commits to it every Tuesday, nor worse because a technically mature component goes several months without a commit. Contributor counts tell us something about the development model, certainly, but on their own they tell us rather little about the quality, openness, usefulness or impact of the work.
What interests us more is what is actually being produced - and whether anyone is using it for real decisions.
On that measure OSeMOSYS/CLEWs is doing rather well.
OSeMOSYS and CLEWs have been used in national policy processes in Cyprus, Costa Rica, Türkiye, Uganda, Botswana, Namibia, Columbia,  Lao PDR, amongst many others — informing national energy and climate plans, NDCs, long-term strategies, development plans and investment roadmaps - and mobilising billions of USD in development finance that makes a difference. And there is massive academic set of users.
So this is not really software looking for a use case. It is modelling that is already finding its way into real policy processes.
There is plenty happening technically too.
MOSOX is making the algebraic workflow substantially faster while retaining the concise GMPL/MathProg formulation. In our testing it is also faster than equivalent PuLP workflows, while requiring far less software syntax between the modeller and the equations. That is important to us: the mathematics remains readable and challengeable, so a human stays genuinely in the loop, while the faster and simpler machinery also makes the workflow much friendlier to AI-assisted automation.
MUIO tackles another important problem: ease of use. It puts a graphical interface around OSeMOSYS and lowers the barrier for people who should not have to become software engineers before they can interrogate an energy-system model.
OSeMOSYS Global provides an open route into large-scale modelling.
And there is a fairly major advance currently going through testing which allows multi-time-step resource tracking, substantially improving the efficiency of systems-of-systems modelling where resources, infrastructure and other commodities need to be tracked across interacting systems. The team have been working hard on that over the summer. Hold tight - 🙂 as I said, you'll love it when it lands 🙂
Those seem to me rather more meaningful indicators of activity than whether a GitHub graph happens to look busy in a particular month.
There is also something slightly important in the spirit of this discussion. The whole point of open modelling is surely not simply to stand outside a repository and count the people already inside it. It is to make the code, mathematics, documentation and community sufficiently open that others can inspect them, criticise them, use them and improve them.
That is what we are trying to do with OSeMOSYS/CLEWs: keep the mathematics visible, make the machinery faster, make the tools easier to use, publish the teaching material, support people openly and increasingly connect the modelling to actual policy problems.
So yes, by all means count commits and contributors - they are useful pieces of information. I just would not mistake them for a measure of the health or value of the ecosystem.
If we are making a scoreboard, I would probably add technical advances, usability, reproducibility, learning resources, academic and real policy use alongside the GitHub statistics.
And if anyone on this rather large list thinks OSeMOSYS/CLEWs should have more contributors, there is a wonderfully straightforward way to improve that metric:
come and contribute. 🙂
Or, if you want to use it for something useful - as hundreds already have - without [shock horror ;]] adding to the GitHub commit count, feel entirely free to do that too. 🙂
Best, Mark


Sent: 16 September 2026 21:26

Robbie Morrison

unread,
Sep 18, 2026, 8:03:06 AMSep 18
to openmod-i...@googlegroups.com

Hello Mark, all

Mark raises many points related to the sociology and practice of open‑source development. Beyond using approved licenses and working in public, there is no one correct approach to FOSS development. Projects are otherwise free to choose and evolve their own norms and practices in response to their circumstances, needs, and objectives. However, a number of common themes have emerged for successful projects, as debated and documented over the last three decades.

Public development

One key theme is that all development must take place in public unless compelling reasons dictate otherwise.

One such instance would be security fixes. I cannot think of an equivalent that would apply to open energy system modeling frameworks — legitimate concerns over critical infrastructure usually manifest in terms of technical specifics rather than the crude engineering characterizations found in such frameworks.

A distinction between the mainline code and release candidates, work‑in‑progress and/or experimental forks is important. These variants should normally reside in public and in the same git repo. Git allows easy switching between branches, this being one of its key draw cards. Small improvements developed remotely are an exception to this rule, whereby individual developers can create and test patches locally before submitting pull requests.

University degree projects may require that students undertake their work on private forks (see dedicated section later). However this does not preclude the general hum of bug fixes, minor improvements, and code refactoring that typifies most software projects. And additionally, public discussions on issues, features, and patches, and also general matters like development priorities and roadmaps.

Forking comes with costs. Developers are faced with either progressive drifting away from the mainline or having to periodically rebase with the mainline and fix discrepancies. It is usually best to get forked developments pulled into the mainline at the first appropriate opportunity so they become integral to the project and available to all.

Undertaking core development in private while maintaining a "shopfront repository" to provide your project with free and open source software (FOSS) credentials is clearly unacceptable practice. I guess we can all agree on that.

FOSS culture more generally

An early treatise was The Cathedral and the Bazaar by Raymond (2001) — which I recall was read avidly when it first rattled around the internet in 1998. A more recent academic treatment is Gardler and Walli (2022) who make a clear separation between the rights and permissions contained within software licenses and the adopted form of development. They comment, rather adversely (page 44):

In some cases the owners of the software may choose to maintain a development model in which only a very limited number of people are able to participate in the software development decision-making process. This may influence potential users' decisions to use the software or not, which in turn affects the likelihood of third parties contributing to the production of the software.

Gardler and Walli later observe that the Open Source Initiative (OSI) describes open source as "a development method for software that harnesses the power of distributed peer review and transparency of process".

Contrast this sentiment with the emerging industry colloquialism "code theater", which describes the practice of creating the public illusion of an active, collaborative open-source software project when the actual engineering work, core decisions, and true development history occur entirely in private.

Project governance

Project governance can be either loose and implicit or careful and formalized.

I know of three significant projects/organizations within the openmod that are currently formalizing their governance objectives and practices. These processes requires a lot of effort and consultation (if anyone wants to share details, please do). I see these developments as a sign that our niche area is maturing.

Gardler and Walli (2022:54–56) discuss governance models, ranging from centralized (the Linux kernel) to distributed (or meritocratic). Brock et al (2022) cover the more formal aspects of FOSS in depth.

Community health metrics

I believe that community health metrics, along with non‑quantitative information, can provide valuable insights for both internal and external audiences.

The Linux Foundation (LF) has recently become active in this area through its Community Health Analytics in Open Source Software (CHAOSS) initiative. Here are a couple of groupings of metrics that relate to the current discussion:

This posting is not the place to make unstructured health metric comparisons between various energy system projects. Readers might wish to check their favorite projects hosted on GitHub to see what their reported activity profiles show. Shopfront repositories will, of course, perform badly.

Academic considerations

The academic dimension of FOSS development has not generally attracted much attention from the FOSS world, aside from recent interest in research spin‑offs and commercialization (Meeker 2026). This section considers some questions relevant to energy systems modeling for public policy support.

A graduate student conducting research for a degree programme using mainline source code, particularly if methodological, should probably create a private fork and work solely from that. The student can submit pull requests at strategic points or just once at the end of their studies. Research that relies on implementing new codebase features risks being replicated by skilled developers elsewhere. While individual projects can elect to freeze certain development routes to protect graduate research, other projects might not be aware of, or wish to be bound by, such restrictions.

This forking strategy does not remove the mainline project from public view, it only hides those lines of work reserved and related to graduate research.

I took the opportunity to check with FOSS projects located in academia for clarification on the above and my remarks were confirmed (again, if anyone wants to comment further, please do so). One university researcher remarked:

Many PhD students have developed [xxx] techniques using [project], but it would be unwise to keep the code in a public repo. Working from a private fork of [project] is the most sensible option.

Deep code development for energy system modeling frameworks is often undertaken by masters and PhD students, so the considerations under discussion here are material.

Di Cosmo et al (2026) offer observations on reusable research software development practices that are also applicable here. Specifically, the need to archive codebase snapshots as part of the scientific literature, something not common in general development. This practice benefits from having source code in genuine public repositories where they can be labeled and found using git tags — or better still, fine‑grained SWHID identifiers (Bethencourt 2026).

Software Heritage can only crawl repositories it can access (Di Cosmo 2020). If a research project uses shopfront repositories (for whatever reason), this process breaks down and the public scientific record becomes diminished as a result. Ditto for AI training and subsequent deployment for model building (Brown 2026).

Gruenpeter et al (2021) define reusable research software by extending the principles underpinning FAIR/O data, where the A is accessibility.

On contributing

Those considering aligning with an energy modeling project, or perhaps just contributing to some specific component, should conduct their own due diligence regarding licensing, code quality, project governance, and development activity.

I hope this and earlier postings by me offer some pointers at to what to look for in this regard. The activity reports on GitHub can be particularly informative. If need be, ask key people in the project under consideration to explain their development processes before you decide to get involved.

Similarly, if you disagree with some of the development practices for a project you are contributing to, speak out and try to find solutions.

References

▢

with best wishes, Robbie

PS: Small clarification: I should have earlier written (note italics): "Just adding unmodified license boilerplate to a code repository in isolation is legally meaningless."

Mark Howells

unread,
Sep 18, 2026, 8:34:04 AMSep 18
to Open Mod
Dear Robbie,
Thanks - and I think this probably gets us to the interesting point.
I agree with much of what you say about the virtues of transparent development, public discussion, good governance and making it easy for people to contribute. Where I suspect we differ slightly is in treating one particular development workflow as a requirement of openness.
I don't think work has to be placed in public before it has been properly tested simply to demonstrate that development is occurring. There is an important distinction between an open codebase, an open development process, work in progress, and a stable release. Different teams - particularly research teams - will draw those boundaries in different places. Indeed, as you point out yourself, sometimes there are perfectly good reasons for development to take place in a private fork before being contributed upstream.
Perhaps open-mod & open-source is a broad church.
That is actually one of the things I rather like about the OSeMOSYS ecosystem. Someone can work directly on the formulation, build tooling around it, create an interface such as MUIO, improve compilation through MOSOX, develop a CLEWs application, teach with it, interrogate a model, use it in a policy process, or simply download a stable version and get some useful work done. Not all of those people need to behave in exactly the same way - or appear in the same GitHub contributor count - to be useful members of the ecosystem.
Your points on governance, reproducibility, archiving and community-health indicators are useful ones, though. I think it would actually be interesting for us to describe the health ecosystem level rather than repository by repository: releases and technical developments, contributors, documentation and training, reproducible models, downstream applications, academic use and policy use ....... as well as ....... conventional GitHub activity.
That might give us a rather richer picture of what an open modelling community looks like.
And, as before, anyone reading who would like to improve the OSeMOSYS/CLEWs/MUIO/MOSOX/SDKs/OnSSET/EAE/OnSTOVE/FinCore/FinTrack etc etc contributor statistics is extremely welcome to do so. :-)
Best, Mark
Ps happy to take this to a 1:1 discussion if more useful.

Sent: 18 September 2026 13:02

Robbie Morrison

unread,
Sep 18, 2026, 9:30:56 AMSep 18
to openmod-i...@googlegroups.com

Hi Mark

Thanks.  GitHub and similar platforms allow different branches for different purposes: the mainline branch (now labeled main), release‑candidates RCx, bugfixes a,b,c, experiments X,Y,Z, and so on.  The mainline is what users see by default.  It is usually based on the latest release candidate, now tested and approved by the maintainers and given a suitable version string.  Adventurous users can opt for one of the bleeding‑edge branches.  All of this contained in the one public‑facing repository.  Note that I did mention early some exceptions to public development for specific use‑cases, namely: security fixes, minor developments and, in particular, academic forks.

This is all established practice, now we have git.  I've been involved in open‑source development for 25 years.  I recently filed a bug report for emacs, which was patched a week later.  I was kept in the loop while developers confirmed, triaged, and fixed the admittedly minor problem with a one‑line modification.

You say that the OSeMOSYS development model is necessarily different from established practice.  However, in my view, the model you describe risks crossing the boundary into closed‑source development, carrying only the benefits of significantly lagged source‑available software.

You also indicate (in two different emails) that the real development for OSeMOSYS occurs somewhere else — which I am not privy to unless I do something specific?  Sign an NDA?  Am granted access a private repository?  What exactly?  This is a serious question.

I think our discussion should remain public.

best, Robbie

Mark Howells

unread,
Sep 18, 2026, 10:17:17 AMSep 18
to Open Mod
Dear Robbie,
Happy for the discussion to remain public. My suggestion of a 1:1 was simply to avoid monopolising a rather large mailing list, not because there is anything confidential to discuss.
But I think I should correct one point quite clearly.
I have not said that “the real development for OSeMOSYS occurs somewhere else”, nor have I suggested that anybody needs to sign an NDA or obtain privileged access to some secret OSeMOSYS repository. That is an inference you have introduced, rather than something I wrote.
What I said was much more mundane: there is development work being undertaken and tested before it lands.
That is not the same thing as maintaining a deliberately misleading “shopfront repository”, and I think it stretches the terminology rather a long way to suggest that testing work before publishing it risks crossing some boundary into closed-source development.
Indeed, your own history of deeco seems particularly relevant here.
In your November 2025 account of deeco you write:
“deeco was fully implemented and well tested when it was made public.”
You then contrast that with projects which go public much earlier and conclude:
“Both strategies are legitimate, of course.” — Morrison (2025), A social history of the deeco codebase, section “Open sourcing plans”. [1]
I agree with you Robbie. And that is the distinction I have been trying to make.
Your history of deeco is also rather useful because it distinguishes between the legal and social dimensions of open-source development. You explicitly write that these are separate, and that a codebase can legitimately be open source independently of whether a surrounding community has yet developed. [1]
For completeness, the Open Source Initiative's formal Open Source Definition is similarly framed around the rights attached to distribution - access to source, redistribution, modification and derived works - rather than prescribing the branch structure or publication timing of work-in-progress development. OSI separately and quite reasonably describes distributed peer review and transparency as important benefits of the open-source development model. [2][3]
I am certainly not arguing against public development. It is often excellent practice. Public branches, issues, pull requests, roadmaps and discussions can all make collaboration easier, and OSeMOSYS already makes extensive use of precisely those mechanisms.
What I resist is the stronger proposition that every line of ongoing research development must appear immediately in a public repository, otherwise the project begins to resemble closed source.
In this particular instance there is also a very practical reason.
The development I referred to concerns the temporal representation of interacting resources and commodities. In broad terms, we want to allow different commodities to be handled at temporal resolutions appropriate to the physical systems they represent, while still allowing those systems to interact.
That matters for CLEWs-type systems-of-systems modelling. Electricity may require comparatively fine temporal representation; embodied materials, land, water or other resources may behave on very different timescales. Forcing every part of an integrated model through the same temporal granularity can create a great deal of unnecessary computational burden.
It is potentially a substantial improvement.
Precisely because it changes something fundamental, however, we would like to establish that it behaves sensibly before inviting other people to base research or policy analysis upon it.
New formulations have to be checked. Edge cases have to be explored. Results need comparison against the existing formulation. We need to know that greater flexibility in one part of the model has not introduced unintended behaviour somewhere else.
For policy-facing research software, I regard that as responsible development, not closed development.
And it seems entirely consistent with the principle you articulated from your own experience with deeco:
“Both strategies are legitimate, of course.” [1]
But perhaps this is a good point to return to what started the thread, because I would hate an interesting discussion about development practice to obscure what is actually being made openly available.
CLEWs-EU is now publicly available as both an aggregated EU27 model and a nationally disaggregated model. It integrates energy with land and water within the OSeMOSYS framework; DIAMOND describes the release as fully open source, with scripts, model inputs and assumptions provided openly. The public repository contains the model and links directly to the documentation and archived releases. [4][5]
That, to me, is the substantive news here.
People do not need an NDA or our permission to inspect it.
Download it. Run it. Read the equations. Examine the assumptions. Question the data. Fork it. Test it. Break it. Improve it. Teach with it. Build something we have not thought of.
And there are two rather immediate opportunities to do exactly that.
First, DIAMOND is holding the CLEWs-EU webinar on Tuesday 22 September 2026, 13:00–14:00 CEST. It is explicitly aimed at modellers who may want to apply or extend CLEWs-EU, or use parts of it that might be useful and will cover the methodology, structure, documentation and openly available code and data. [6]
Second, for anyone who prefers building things to discussing how things ought to be built, the OSEAS Open Source Hackathon is currently inviting students, professionals and independent developers from any country. Teams work remotely for roughly four weeks on real open-source energy-access projects, supported by maintainers and mentors, with contributions intended to flow into live projects rather than disappear at the end of a weekend. Registration closes today, 18 September, and the kickoff is on 28 September. [7]
That strikes me as the fun part of open source: code people can actually inspect, tools people can actually use, difficult questions people can actually ask, and communities in which people can actually build things together.
Free as in speech; and there is rather a lot here that is free as in beer too. :-)
So no NDA required, Robbie.
Come to the webinar. Join the hackathon. Fork something. Find something wrong. Make it better. Put the result back into the commons.
That was rather the point of my original email.
Best, Mark
References
[1] Robbie Morrison (2025), “A social history of the deeco codebase”, Open Energy Modelling Initiative forum. See particularly “Open sourcing plans”, containing the statements that deeco was “fully implemented and well tested when it was made public” and that “Both strategies are legitimate, of course.”
Morrison (2025) — exact deeco passage
[2] Open Source Initiative, The Open Source Definition.
Open Source Definition
[3] Open Source Initiative, About OSI — including its description of distributed peer review and transparency of process as characteristics/benefits of the open-source development method.
Open Source Initiative — About
[4] DIAMOND, “CLEWs-EU final public version released” — describes CLEWs-EU as a fully open-source integrated model and states that scripts, input data and assumptions are provided openly.
DIAMOND — CLEWs-EU final public version released
[5] CLEWs-EU public repository — aggregated and disaggregated models, documentation and release links.
CLEWs-EU GitHub repository
[6] DIAMOND, “Introducing CLEWs-EU: A Nexus Model for Europe’s Energy, Land, and Water Futures” — webinar, Tuesday 22 September 2026, 13:00–14:00 CEST.
CLEWs-EU webinar
[7] OSEAS Open Source Hackathon — four-week remote hackathon with real open-source energy projects; open track available internationally; registration deadline 18 September 2026 and kickoff 28 September.
OSEAS Open Source Hackathon


Sent: 18 September 2026 14:30

Robbie Morrison

unread,
Sep 18, 2026, 12:38:57 PMSep 18
to openmod-i...@googlegroups.com

Hi Mark

My remark about legitimate strategies was related to an open‑source launch, not a development practice. Quite different. The deeco codebase is irreverent to this discussion in any case. For those interested, here is an historical timeline.  The project was abandoned over two decades ago after the SCO Group retired key programming libraries.

The question at this juncture is simply this: where does the development of OSeMOSYS (say the MathProg variant) actually take place? Could you provide a URL?   Then we can talk about how potential users can clone the codebase and perhaps later contribute back.

Looking into the recent peer‑reviewed literature, the URL given in Tan et al (2025:13,24) for OSeMOYSYS and noted as "actively maintained" is this:

Readers can then click through to the MathProg variant as follows:

And then select the master branch and then the last commit: 7 Nov 2024. That is 97 weeks or almost two years back. There are also 42 open issues.

Are you suggesting that this classes as "actively maintained" as per Tan et al ? Given that the main branch has been inactive for almost two years. Where exactly does the unpublished development that you have referred to three times actually take place? Or can you not disclose that?

Could someone else from that paper who is also reading this thread perhaps comment?

Source

best, Robbie

Mark Howells

unread,
Sep 18, 2026, 1:11:44 PMSep 18
to Open Mod
Dear Robbie,
Yes - the repository you link is the public GNU MathProg implementation, and your observation about its main branch is fair: it has not seen a recent commit. Its been stable for a few months.
There is, however, development and testing under way on a new version of the formulation before it is contributed upstream. I don't have access to that local development environment myself, so there isn't another public URL I can point you towards today. But I'll be sure to get it your way after its been tested. I think you love it 🙂.
But, I also I think that answers the narrow question.
Where I would be cautious is in using the commit history of that one implementation as a proxy for whether the OSeMOSYS/CLEWs ecosystem - or the people working within it - is active.
There has actually been quite a lot of recent, openly available output.
One example is MUIO. Its current public release series continued through this year, and the present implementation exposes User-Defined Constraints directly through the modelling interface. Users can formulate additional equality or inequality constraints over technology capacity, new investment and activity without rewriting the core OSeMOSYS formulation. The implementation and documentation for doing that are themselves open. [1][2]
That is quite a significant shift in what users can do. Instead of every new policy or system constraint requiring a centrally maintained variation of OSeMOSYS, users can construct a very large range of their own formulations on top of the stable model.
There is also a more recent example which perhaps illustrates the point even better.
On 24 August 2026, version 3.0 of the Starter Data Kits Database for Whole Energy System Modelling in Sub-Saharan Africa was published openly on Zenodo. [3]
These are not simply documentation or illustrative examples. The release contains 49 downloadable national model-data workbooks. Each Starter Data Kit contains 12 model parameters, 199 technologies and 30 useful-energy demands, covering inputs such as demand, installed capacity, costs, efficiencies, emissions factors, fossil resources and renewable-energy potentials.
The intention is that people can take the complete dataset or selected components and start building country-level, sector-coupled energy-system models rather than beginning with an empty spreadsheet.
So, if anyone on this list has been looking for an excuse to try OSeMOSYS, there are now 49 rather good ones. :-)
The learning infrastructure has also been substantially refreshed this year.
The Open University's OpenLearn Create platform published the March 2026 Climate Compatible Growth collection, containing 24 courses. [4]
That collection includes the 20-hour Energy System Modelling using MUIO/OSeMOSYS course, first published on 25 March 2026; the 27-hour Introduction to CLEWs, also first published on 25 March and most recently updated on 17 August 2026; and the 40-hour Advanced CLEWs/CLEWs++ course, first published on 25 March and updated on 5 May 2026. [5][6][7]
And the collection is considerably broader than OSeMOSYS alone: it also includes OSeMOSYS with FlexTool, OnSSET, OnStove, MUSE, MicroGridsPy, financial modelling tools and other material intended to make open modelling methods usable rather than merely downloadable. [4]
Then there are the other public pieces of the ecosystem: OSeMOSYS Global, MOSOX, CLEWs-EU itself, the public documentation, model examples, issues, training and community support.
So I think there are two slightly different questions here.
One is: has the GNU MathProg main branch seen a recent commit?
No - your observation there is correct.
The other is: are people actively developing, testing and releasing useful things around OSeMOSYS and CLEWs?
The public outputs above make that fairly easy for people to judge for themselves.
There is also, I think, a useful development principle behind this.
For stable software, make as much as possible inspectable, reusable and extensible. Give users mechanisms such as User-Defined Constraints so that they can build things that the central development team never anticipated. Publish model data, documentation and teaching material so that other people can actually get started.
But when changing something fundamental in the mathematical formulation, test it properly before encouraging researchers and policy analysts to depend upon it.
I don't see those things as being in tension. To me they are complementary parts of responsible research-software development.
And perhaps the useful outcome of this discussion is simply to invite more people in.
Download one of the new Starter Data Kits and build a country model. Take MUIO and invent a constraint we haven't thought of. Work through the CLEWs material. Try CLEWs++. Run MOSOX. Build something with OSeMOSYS Global. Pull CLEWs-EU apart. Find something wrong. Open an issue. Submit a fix. Improve a dataset. Teach with it.
And when the formulation currently under testing has reached the point where it can sensibly be put in front of users, I hope people will scrutinise that just as closely.
That seems to me a rather healthy way for an open modelling ecosystem to work.
Best, Mark
References
[1] MUIO documentation — User-Defined Constraints:
MUIO equations documentation
[2] MUIO documentation — UDC parameters and examples:
MUIO parameters documentation
[3] Plazas-Niño et al., Starter Data Kits Database for Whole Energy System Modelling in Sub-Saharan Africa, version 3.0, published 24 August 2026:
Zenodo record 22086328
[4] Climate Compatible Growth — March 2026 course collection:
OpenLearn Create March 2026 collection
[5] Energy System Modelling using the Modelling User Interface for OSeMOSYS (MUIO), first published 25 March 2026:
OpenLearn Create OSeMOSYS/MUIO course
[6] Introduction to CLEWs, first published 25 March 2026; updated 17 August 2026:
OpenLearn Create Introduction to CLEWs
[7] Advanced CLEWs — CLEWs++ modelling, first published 25 March 2026; updated 5 May 2026:
OpenLearn Create Advanced CLEWs/CLEWs++
[8] MUIO public releases:
OSeMOSYS/MUIO releases
[9] OSeMOSYS Global:
OSeMOSYS Global repository
[10] MOSOX:
MOSOX repository
[11] CLEWs-EU:
CLEWs-EU repository


Sent: 18 September 2026 17:38

Robbie Morrison

unread,
Sep 18, 2026, 1:43:02 PMSep 18
to openmod-i...@googlegroups.com

Hello Mark, all

I don't think I need to respond further at this juncture.

Please say hi to Claude from me!

best, Robbie

Mark Howells

unread,
Sep 18, 2026, 2:25:20 PMSep 18
to openmod-i...@googlegroups.com
Will do, Robbie.
Though I should warn you - he may ask for the URL to the repository where that joke was developed. 🙂. 
Best, Mark

Sent: 18 September 2026 18:42

Robbie Morrison

unread,
Sep 18, 2026, 3:54:18 PMSep 18
to openmod-i...@googlegroups.com

Mark, that's fine .. the joke was approved by the Open Source Initiative and has an SPDX identifier from the Linux Foundation, have a good weekend, Robbie

Mark Howells

unread,
Sep 18, 2026, 4:48:06 PMSep 18
to openmod-i...@googlegroups.com
😂 Touché, Robbie.
And genuinely - thanks for the discussion and for keeping us honest. We may come at some of this from slightly different directions, but I think we want much the same thing: useful work, done well, and made genuinely open for other people to use and improve.
Have a really good weekend.
Best, Mark


Sent: 18 September 2026 20:54
Reply all
Reply to author
Forward
0 new messages