Hello. Adrian here. Over the past few months, off and on, I’ve been thinking about version control. As a company that writes lots of software, it’s a pretty central tool for managing source code: keeping track of what’s changed and why; letting us organise releases; etc. We also take that approach into our non-software work, storing the design files for the electronics or our CAD work for 3D printing or laser-cutting.

With many of our products and projects being open-source, it isn’t just an internal matter. Because we need to share the design and source files for people to use to build their own or remix or repair, we need to open up at least some of our version control system to folk outside of MCQN.

Why are we looking at this sort of thing?

This isn’t a new problem for us to address; however, there are a number of factors leading us to re-think it:

  • Museum in a Box had settled on Github; whereas MCQN has a self-hosted instance of Gitlab for private repositories, and only uses Github for public, open-source ones. Now that Museum in a Box isn’t a separate entity, it would be good to consolidate things.
  • Github has always been an odd fit for open-source infrastructure, given that it’s a private for-profit company; and these days part of Microsoft. There’s been a long-running campaign to #GiveUpGithub and the reasons to do so keep ratcheting up.
  • There’s always been a risk that any of the centralised solutions (Github, but also Gitlab.com, Bitbucket, Google Code, Sourceforge…) would go away or become otherwise unavailable:
    • Google Code was at the whim of Google, so got turned off when it wasn’t useful to them
    • Sourceforge went down the ad-funded route, getting steadily less usable; so everyone switched to Github
    • The YouTube experience of “This video is not available in your country” is always a possibility if a country decides that your country is one it doesn’t want its companies to deal with. That’s likely been a lived experience of folk in less privileged countries than we are; but with the Trump tarriff deals and the like, it’s looking more of a risk for Europe.
    • Similarly, but from the other side, it’s possible that legislation in our country might cause foreign-based companies to turn off access. We’ve seen that with US companies blocking any Europeans rather than work out how to deal with GDPR; and the UK is just starting to work out the impact of the Online Safety Act from domestic and foreign sites.

Single Points of Failure Considered Harmful

So the standard open-source geek response to such concerns is that you should just run your own instance of your preferred open-source solution. What’s wrong with that?

Well, a few things:

  • Search. If we build something open-source that would be useful for others to use, how do they discover it? How are they going to find our instance?
  • “User overhead”. Maybe this isn’t a problem, but do we want to be managing user accounts on our instance for the world when they’re reporting and commenting on bugs?
  • Swapping one single-point-of-failure for another. What happens to the code if you shut off your server? Or when you die? The commons would then lose your contributions too.

The first two would probably (although distributed identity has failed to succumb to many technical attempts to tame it, so far) be amenable to most-technical solutions. And any federated or decentralized approach would need to solve them too.

The last one, though, is one that feels more important; if we’re interested in building and sustaining a code commons.None of us are able to write and build all of the software we need. Open-source is a collective endeavour and managing it should be too.

So it turns out that issue trackers and a wiki are useful for all sorts of collaboration. Possibly adding collaborative document editing (a la Google Docs) and maybe discussion groups too would be useful.

It would be really nice if there was a tool that could let you host a git repo, but would also let you just have the issue tracker and wiki options without needing a repo. And without lots of talk and pointing folk at a repo that is or isn’t useful to that project.

DoES Liverpool uses the issue tracker and wiki features of Github to manage the tasks and maintenance jobs in the physical space. Adrian gave a talk about that usage at the Festival of Maintenance a few years back. It works well, but all of the code-focused parts of Github are confusing for newcomers who don’t know anything about coding and just want to help to keep their makerspace running smoothly.

Making the issue tracker and wiki more prominent could also lead to developing more tools to make it easier to search through the wiki and closed issues, so the knowledgebase built up in those was more readily accessible.

And over time maybe it could add more non-coder-friendly ways to introduce source control to more folk. Maybe Kicad and FreeCAD could start to add in diff tools to show how comparing non-basic-text versions is possible?

What (I think) I’d like

I think I’ve got a decent handle on the issues and the features that would make sense, both to MCQN as a company and to the wider software ecosystem.

To summarize, our ideal version control system would have these features and capabilities:

  • An issue tracker
  • Ability to include, or integrate with, a wiki
  • Option for a git repo (integrated into the issue tracker, etc. in the same way Github, Gitlab, etc. do so you can easily tie commits to issues. Much of the additional commentary and decisions happen in the issue discussion, so linking that to the code commits is key)
  • Open-source so we don’t get tied into a single provider. It gives MCQN the option of hosting it for its own for private projects, if we want; and switching providers if one changes its pricing or terms in a way with which we don’t agree
  • A model of federated common instances, so MCQN can host its open projects in the commons (to protect from MCQN going away)
  • Scope for mirroring repos between commons. To provide resilience against other commons instances going away or becoming inaccessible.
  • Federated search across commons instances. This is a key requirement for the federated approach. Discoverability of repositories is what has driven the centralization so far
  • An easy way to import repos (including issues and wikis) from Github and Gitlab to migrate from those hosts to the new commons and private instances. Maybe there should be a standard format for code-and-issues-and-wiki for data portability?

And to address the risk of us going away and depleting the commons (and to share the cost and maintenance of running the service), we’d favour joining/founding some sort of collective or co-operative approach.

Does anyone know of anything that fits the bill? Which software solution is nearest to our requirements? Or is headed in a similar direction? Anyone want to join us?