The Future Home of Open Source - Buenos Aires 2025

[music] Hello everybody. Um, I forgot my Irish jersey because I heard we qualified for the World Cup as well. Okay, so um, I have an admission to make first. Um, I'm not here to talk about Ethereum and I'm not here to talk about public goods funding, but maybe public goods forges. Um, so the current home of open source seems to be GitHub.

Um, sorry about the size of that. [laughter] Um, but maybe a quick show of hands for any projects. Are you pushing your code to GitHub right now? Is what about not GitHub? Oh, cool.

Three. So, uh, the recent years have shown us that GitHub might be a scary foundation for, uh, projects, open source projects. Um, they're banning people based on their, uh, location where in like countries. Um, if you search uh GitHub bans, you'll find Iranians, Russians, Crimeans uh losing access to their repositories. Um, and even more recent news, co-pilot data or co-pilot is being trained on your open-source data.

And I even did a quick Google of are they doing it on private repositories and there's been no um public uh admission of GitHub to say that they're not. So where should open source projects go next? Um oh the formatting on that is terrible. Um anyways uh I have a non-exhaustive list here. Um, we have GitLab, Forge, Joe, Tangled, and Radical.

I'll quickly run through each and uh discuss some pros and cons. For GitLab, it's open core, so part of it is open source um and then part of it is enterprise. Um they that means you can self-host easily and you can fork their uh core and make the changes that you want. Supports issues and pull requests as per usual. Forgejo um it's a fork of git.

Uh it's federated. Uh what I like most about them are they're trying to they are trying to implement a federated forge format or F3 for short so that uh federated [snorts] forges uh speak the same language and developers can move uh between them easily. Um they're owned by uh um the the Codeberg Foundation. Um, so they're working on, yeah, just a more open, incredible exit type of forge. Then we got the new kids on the block, Tangled, that are working on App Proto.

Um, if you don't know what App Proto is, it's the protocol behind Blue Sky. Yeah, it's pretty cool. And they're, uh, building on top of like the social element of Blue Sky. Blue Sky, you've already got your identity with the ID PLC. Um, and on top of that, they also love JJ or Jiu-Jitsu VCS and are working with some like cool design techniques in their forge.

And then last but not least, uh, Radical. So, I am one of the maintainers on Radical. Um, Radical is a decentralized forge. We got our issues in our patches or pull requests and one thing we want to do is try and make it extensible as well. So when we talk about radical one of the comments that we usually get usually on hacker news is what git is decentralized but people go to github which is centralized.

It's not. Um, but of course there are projects that still use mailing lists, which is also decentralized in a sense, but we're trying to make it even easier to use than a mailing list. Um, so how radical works is basically uh bundling all your data into the git objects themselves. Uh so you have your issues, your patches and other extensible data alongside your code. That means all your data is local first.

It's even offline first. I often uh get on a plane from Dublin to London um where I don't have any Wi-Fi, but I have 40 minutes to continue working. [snorts] And then when I uh get off the plane, I can sync back up with the network. Um, the network is just basically a TCP stack with some noise encryption uh that send gossip messages and this initi initiates get fetches. I'm so sorry about these slides, but this is a essentially a screenshot of our uh our Heartwood repo and its issues on the CLI.

And the same again with patches. But as I said um we want it to be extensible. And uh one question that we always get is does it have like a CI an answer to CI and one of our team members uh does work on CI. Um you need CI and CD for the health of your project. it would be unrealistic to come along with a forge and say we don't support any like CI system.

Um so what does that CI system look like in practice? Essentially any node can um run CI on behalf of a project. Uh so we're getting back into the theme of the commons. Um so as nodes hear about gossip they can decide to run CI and report results. Um but then obviously you need to curate your list of which nodes in the network do you trust.

Uh the radical CI system uses the idea of adapters. So essentially you can bring your own CI. Um there's adapters for um basically running natively if you just want to like quickly test uh your YAML file. Um but there's adapters for ambient which is a more experimental CI system. Uh GitHub actions if you want some free compute from your centralized service.

uh Woodpecker, Jenkins, Concourse, and apparently it's easy to write an adapter uh as long as your CI system makes it easy for you. Here we got an example of a simple bash script that says your CI always fails. That's how easy it is. It's just a bash script doing input output. Diving a little bit deeper.

Um so uh radical you run a node on your computer your server and uh as I said it does gossip it does get fetches and these get converted into events. These events get spit out into a control socket and uh the radical CI broker basically listens to these events and oh yeah sorry I'm covering the slides but parses them filters them and uh like goes through your YAML definition for when to run uh CI run. So maybe uh whenever a maintainer pushes to your main branch then make sure you run CI or uh if any patch comes in make sure you run CI. What exists today? Um as I said there's a configuration file in YAML.

Um you can build and test on any chosen changes. So the that YAML file is a um a predicate logic so you can um come up with whatever kind of workflows you need. um it's distributed. Uh so in the same way that uh issues and patches are data, there's this idea of a job co which basically says uh or like has a node and it see um a URL to the results and whether it succeeded or failed and it also has HTML reports but these are currently not distributed. Um where we need to go with that uh we need to build with better integration with distributed notifications.

So sending these results um throughout the network easier um more CD kind of stuff. So, storing artifacts, um trust around artifact building, um better better run logs, and um a UI for controlling these uh these CI runs. So, being able to trigger them or stop them uh manually rather than through the automatic process. And that's pretty much it. I think I flew through that.

But [laughter] um yeah, so the other mention is that uh there's another team called Radical Garden and if you go to radical.garden uh today you can sign up to waiting waiting list. Essentially their aim is to provide a kind of out of the box hosted solution. Um, so it's still built on Radical, but um key it provides like custodial keys so that you don't have to look after your cryptographic material. Um, a web application for issues and patches.

Um, kind of like your familiar forge. Um, and of course they're going to bundle uh the CI work as well. Um, but if you want to get started using Radical today and play around, go to radical.xyz where you can find a download page, user guides, um, and a link to our, uh, Zulip community, uh, radical.zip chat, and come say hi on FinThops there, and we would love to help you uh, working on Radical.

So, if you're working on a decentralized project, maybe you should use a decentralized forge. Put your code where your mouth is. [music] Thank you. [applause]