This post is part of the EON series.
Or when eOn is not EON…
Open source in academia remains fraught by existing “structures of power”, as a
case-study, let’s consider a code I worked on and maintain called EON (or
eOn, now). The exact details of the methods within are not primarily of
importance, but its history and license are. Historically under the GPL v3
around 2001 and 2003 by an older student (Prof. Graeme Henkelman) of my PhD
advisor (Prof. Hannes Jonsson). The code then got a facelift a few times, by Dr.
Andreas Pedersen and contributors, along with a refreshed publication in 2013,
primarily driven by Graeme. Around 2018, there was a decision to shift the
project to BSD-3, so the Amsterdam Modeling Suite could “fold” the code,
developed at the University of Iceland and UT Austin into their software 1.
In 2019, after joining the doctoral program with a Icelandic Research Fund
doctoral grant, I had taken on the task with some folks at SurfSARA, to
implement a Gaussian Process Regression dimer methodology for saddle point
searches. The code was rather unmaintained, with no real publications from 2015
or so, no users of the SVN as far as I could tell. Since the code was hosted on
SVN, I started with a private Github instance, TheochemUI/EONgit. Being a
fledgling NumPy developer and with a decade of FOSS under my belt, I began
modernizing the code alongside my scientific work.
This post records the history leading to the Materials Science Community Discourse post on “eOn is not EON”, along with some thoughts about moving forward.
Sometime in 2022, Graeme reached out, on his way in to Iceland for a visit,
…. (private)
In 2024, Dr. Miha Gunde reached out to me for presenting EON at a CECAM workshop on Long Timescale events, at which point I requested that we go public with the Github variant due to the many changes.
Hi Rohit,
This triggered a series of mails as I prepared the SVN migration, including mapping every username therein to appropriate Github handles by mailing all possible prior contributors. The end result correctly records history (eOn contributors) since 2010, at which point Graeme had shifted from CVS to SVN without correctly tracking provenance unfortunately.
Around when I wrapped up my doctoral work, I joined the vibrant group led by
Prof. Michele Ceriotti to support Dr. Guillaume Fraux on their Metatensor
ecosystem. One of the first things in my downtime was of course to integrate
with eOn, generating the cookbook recipe for using eOn for nudged elastic band
calculations over ASE. As part of this effort I announced to the #eon channel
in UT Austin, on July 26 2025, that
hullo, so FYI there’s going to be a conda release of eon today. Mostly because I need it for my cookbook recipe demonstrating the ew-NEB-CI. Might be helpful to y’all too
Even though the actual cookbook didn’t make it through until December 2025 due
to conda-forge review timelines. Some of the graduate students in July reacted
positively to the prefix forge example I demonstrated at the time, i.e.
1# July
2micromamba install -c "https://repo.prefix.dev/rg-forge" eon
3# For the cookbook, December
4conda install eon
but otherwise no response was provided.
In the interim, I published a few papers, and on September 4, 2025 as part of
the conda-forge process, I announced release notes, which Graeme acknowledged
Rohit Goswami
The resulting release notes and website have since been the stable home for the code, both on Github and conda-forge, i.e.:
Over the course of the degree, I had given several talks referencing both
groups, and the strong international collaboration therein, all held together by
mutual respect and trust. Some users on GitHub began to appear, along with
questions on the Discussions and eventually, just before my graduation on
December 19th, 2025, I requested a MATSCI community discourse section for eOn,
since I believed the package was about to be used widely, given its primacy in
my dissertation on efficient exploration of chemical kinetics (ArXiV, Opin
Vísindi).
Things were looking up for the code, I thought, moving upwards to 3.6k downloads
to date of the package on conda-forge.
In 2026, Graeme reached out to chat about “merging” codes, with three students in tow. Slightly bemused, since there had been no issues opened nor pull requests for the entire duration, nor had the SVN been updated beyond trivial details, like in January 2025
Graeme Henkelman
I was more than happy to meet with my Texan friends during my first few days back at work for the new year.
On joining the meeting on Monday, January 5 2026, however, I was confronted with the immediate demand to:
conda-forge recipeThe renaming demand, despite breaking downstream workflows and existing publications from my doctorate, was made with increasing force over the past few days, with one of the students opening a PR to directly take on admin duties on the recipe, and another letting me know privately that
Well, I don’t make the final decisions … I am just doing whatever I get told to process.
which suggests Graeme working through his students instead of his own handle on Github. His own comments were equally non-negotiable
Hi Rohit and all,
Despite the older Fortran routines being present, and compiled even for the conda-forge binary.
Along the way, in advance of the scheduled meeting a few days later, on Thursday,
January 8 2026, the Texans rather confidently decided to contextualize the issue
as they saw it to another conda-forge maintainer, Dr. Jan Janssen, so I got to
hear
(Jan) You forked their original source code of the EON package and then you added a conda recipe for your forked version. This is against the rules of conda-forge which state: “Source is from official source.”
Which of course, made no sense, given that I had been given ample evidence throughout the past half decade that the code I was using and presenting was indeed the official version of the code, something which Jan was originally unclear about
(Jan) As far as I understand, the core question is if the Github Version on the Github Organization from Hannes Jonsson is a successor to the version which is hosted on Graeme’s SVN server or a fork. As long as Graeme says he never gave away the leadership of the project, any version outside his SVN server is a fork and his SVN remains the official source.
Nevertheless, after being better apprised of the situation, including the timeline, did temper his comments down to
(Jan) .. In terms of quoting, I am a scientist and not a lawyer so my comments are just personal experience - no legal advice.
while admitting the Texans were rather less than forthcoming about the history
(Jan) And while I was messaging with you as well as the students from Graeme, I want to emphasize that my focus was to find a compromise. I definitely learned a lot about the background during our conversation and I agree that it is a complicated situation that I currently cannot help to resolve.
To his credit, so far, he has since ignored further entreaties over email by the Texans to accept the “primary author” 2 sources and forcibly revert the code to remove half a decade of changes instead of a standard pull-request based contributing workflow.
conda-forge/coreWhile it is nice to know the opinions of my fellow maintainers in academia, I decided to check in with the actual stewards of the forge on Zulip, where the it was quickly clarified that aggressively “replacing” continually developed versions of a code with an older “original” will certainly not be tolerated, to wit
Rohit Goswami: they’ve also “offered” to “let me” change the name on conda-forge for them to then take up the recipe :‘D
Which should have been, and is in my opinion the end of the discussion, nevertheless Graeme continued to push forward
Calling your recent developments as unauthorized it not right. You are free to fork the code and make changes. The name eon, however, should reside with the original code. You can simply pick a new name, such as neon, or eon-gpr, and shift over to that. Jan has explained to us that there is no problem with this. It only requires that you realize that you have made a modification to a code that has been developed over many years by many people, and so your code is a modification and should be named as such - it is not the original as defined by the primary developers. If what you have done is of value to the community, great, they will adopt it. But you can’t claim that the code is ‘eon’ as originally described in the literature and defined by the primary developer.
To which Jan refrained, having recused on LinkedIn already. Such gaslighting might normally be concerning, but for the ample Git history and mail / slack history demonstrating good-faith stewardship.
Allegedly, the code has become too complicated, and yet, no pull requests for
removing complexity are forthcoming, since the stated intention remains to
remove the past five years of work and build off the older code, i.e. generating
a fork of the existing development. At the moment, despite backing from /core,
the only stance remains declaring that code technically uses eOn over
EON, a fairly ridiculous distinction. The burden of maintainence means not
allowing existing code to break, even though the Texans have been repeated
entreated to collaborate through standard methods, they continue to sulk in the
background, despite a concillatory email from my end
Hello
It remains to be seen how this plays out, but academic rigor and FOSS principles
dictate that there shall continue to be one source for the conda-forge
package, and nothing shall break the existing provenance3.