Governance
This document attempts to clear up my views on this project, its current status, and my plans for it. It explains both what the governance stance is now, and what I want it to become in the future, when the project outgrows me as the single person working on it.
This document was written on . A lot of what is in it is about plans and ideas for the future. Some of those will work out, and some won't survive. If you spot anything out of date, let me know and I'll work to update it.
How long will this project operate?
I have zero intention of stopping work on this project, and I foresee myself continuing it until well into my retirement. I don't think I'll retire in the next 10–12 years, either.
I've worked on open source projects for a very long time: 8–10 years on Clear Linux OS, and about 6, I think, on Lunar Linux. I can do a decade easily. I've already put almost 6 months into this project, and we've only just started and gotten it on the rails.
What if you couldn't?
Good point. I will be making plans to ensure that the project can continue without me should that happen. This will include a transfer of the offline keys, the current build infrastructure, the domain name, and the service provider contract for hosting. Let's put a deadline on this plan: May 1st, 2027. I may not make all the details of the plan public at that time, though. Maybe only a few people will see the full details.
Aside from that, everything is open source. Everything can be cloned and recreated from scratch. Everyone can deploy their own instance of dispatch and start with new keys and their own security posture, and people with existing installations can replace their repositories with different ones and adopt the key fingerprints of any new server.
Who calls the shots?
Me. Auke Kok, sofar@foo-projects.org. Not my current (or former, or future) employers. I've filed Prior Invention declarations stating that the ownership of The Ur Project isn't something a full-time employer can claim.
What about copyright?
Everything built in-house is GPL-3.0-or-later. There will not be a Contributor License Agreement (CLA). The GPL v3 has stood for long enough that I don't see the need to ever renegotiate with all the contributors, or to require them to sign over their copyright. Everyone retains their own copyright if they assert it in their contributions.
GPL-3.0-or-later isn't a requirement. Project-specific code may have other open source licenses. They should be compatible, though.
DCO?
Implied. By submitting a contribution you state that you have the
legal authority to do so, and that you can vouch for its origin, the
same thing a Developer
Certificate of Origin sign-off says. You don't have to add a
Signed-off-by line.
Yes, but what about your employer?
I am currently employed by VergeIO, a company that has developed its own OS, and they employ me to (obviously) help them work on it. The overlap is that both my employer and the project benefit from the work that I do. At the same time, my employer does not fund The Ur Project, or the personal time and effort I put into it. As such, there is a clear separation between what I do as part of my employment and what I do in a personal capacity.
If you see changes and commits authored by my sofar@
address, they were made in my personal time. If you see me contribute
changes as @verge.io, they will go through normal review on
the Forgejo instance, where
everyone can see and review them, and they should be considered external
contributions. That does mean that I might review and accept them myself,
obviously.
What happens to new contributions?
For now, I will review them, and hopefully adopt them, like a normal open source maintainer would. I intend to give every contribution a fair shake, and I will review the incoming patches, bugs, suggestions and feedback as best I can. Contributing explains where each of those goes.
What about LLM/AI use?
Yes. Fine. The stance is the same as that of the Linux kernel
community, which recently adopted a more
open
stance towards AI/LLM generated code. Contributors are allowed to use
them to create contributions. Contributors are still responsible for the
code they submit, and should test and review it before submitting. I
don't want to see Co-Authored-By lines or other LLM
artifacts become part of commit messages.
The dispatch build system has several MCP (Model Context
Protocol) endpoints built in, which I use daily to drive the tasks coding
agents perform for me. That can be writing recipes and doing packaging
work (the designer MCP), license scanning (the license MCP), and other
things, including writing, reviewing and testing code.
What agents may never do is become the deciding factor in content: agents are prohibited from approving package changes. For this reason the build system itself is built so that coding agents cannot access or manipulate the distribution content after it has been promoted.
What I do expect is that everyone who uses LLMs to write anything also spends a lot of time testing what they make, in excess, even. I do so too, perhaps too much in some ways, and perhaps not enough in others. But more testing is always better. We continuously test reproducibility, for instance, and we test multiple images, sometimes many times per day.
What happens if new contributors join?
There is no membership defined at this point. There is only me, and people not part of the project, until I decide that there is. At that point the project is no longer run by just me, but by two people, then three people, and so forth.
At some point I will no longer be able to determine whether it's OK for more people to join, and from then on the members will decide who may join.
What happens if companies want to join?
My desire is that companies have a fair seat at the table, but they must not outrank or overcrowd members. I don't know yet how we can guarantee that. For now, we will not allow companies to join, but we will allow members who represent a company to join.
Corporate governance?
No. My vision right now is to prevent corporations, businesses, commercial entities and other organizations (including non-profits) from obtaining decision-making rights by themselves. Until exact rules are in place, I will retain the final say, as a person not representing any company or organization.
I would consider something like a board or committee calling the shots once there is a rule in place that grants all members representing an organization at most 40% of the total vote, so that individual members always hold at least 60%. But this is just a concept, for now.
I don't foresee or desire that this project becomes part of, e.g., The Linux Foundation, or has something like a Technical Advisory Board (TAB). If there is a need for something like that, we'll look at it at that time. I would strongly prefer not to, though.
What about the project name?
I'm not attached to the name at all. It is just a name, and possibly a poor one. At some point we can change it to something more suitable, perhaps.
What about a more formal organization?
I fully intend to establish a legal entity, non-profit or not-for-profit, in a jurisdiction that benefits both the project and its members.
The project will require funding to keep providing what we promised: a well-tested, compliance-first, fast-turnaround platform for making Linux distributions. It can't exist without demonstrating that it can do this, every day, all days, forever.
I don't necessarily want to handle funding and resources, but it will be necessary to do so early on. I've already invested funds into making this possible, and regular hosting costs are part of daily operation, so there is no way around it. Certain development milestones are going to be gated on obtaining hardware, which might add cost. All of that should go through transparent funding, from an entity that lays it out in the open.
Funding?
Yes. The project will need to accept donations. That could be equipment donated to developers on the team, funding to operate services, or even funding to pay for resources and developers. For now, donations will have to go to me directly.
Will the project ever become a commercial entity?
No. Never. The project should remain a non-commercial entity, run by and for everyone. That can't happen if it becomes a commercial entity, so it should never happen.
Everyone is free to start their own commercial or non-profit organization to promote and support the project. The usual caveats apply: no entity should damage the project by doing something that would be considered illegal or hostile. There will not be any special seats at the table for any of these entities.
I have more questions
Please ask, on any of the channels on the community page. If anything is unclear, I'll try my best to clear it up.
--sofar (aka Auke)