Why neosource

Human written

Yes I know… another forge/codehosting place, what a surprise.

““Isn’t it annoying that we have to use Github. And isn’t it even more annoying that linear is seperate from github? And how hard is it really to make a forge in 2026? Can’t we just use jujustu like operations but just fully in object storage? Making it also fully free to have forks.””

Me, start of 2026

The above was how I actually thought about a forge, now a couple of months later working on “neosource” after work, we know a alot more about what goes into making a forge. Loose git files everywhere? please no, did you know that smart people have worked on that already? “What if we can have multiple git files such that we don’t need to have this one big packfile”, midx existed I just didn’t know about it.

So this is my honest and expensive (more on that later) take on how to make a forge in 2026.

The first fun limitation to put myself in was to not have to rely on any big tech products. Even so, you could say that a managed database, object storage, message broker, email, multiple keyvalues would not neccesarily “lock you in”, but what is the fun in not doing all that yourself. So we decided to make it fully ownable, no other data processor, no services beyond our own (rented, who can afford servers right now) servers.

I know that there are alot of other similair projects:

Product decisions

User/Org namespaces

When signing up you might be asked to login with github, that feels a bit weird… I thought this was a competitor.

We didn’t want to allow users namespace-sitting users who had a github account for a decennia, to not allow moving to neosource. So the decision was to use github as a namespace check.

If your chosen user/org name is taken in github, do a quick login to make sure you actually own that and can take that namespace.

Planning and code in one product

Some readers might now that github has issues and planning stuff. But from my peers, everyone just uses Linear. I always found it quite annoying to need to swap between the two of them, especially as linear gets slow on first load from direct link navigations, and github takes even longer to load up a pr page nowadays.

Ofcourse we shall see if this will happen to us aswell, but it seems like a fun problem to solve. Issues, planning, organizing, PR’ing, should just be together. Linear has been trying to do this during the year, but it does feel scary to press merge on a linear page.

One experiment that would be fun to see, if the seperation of “tickets” and “issues” will make sense in neosource. Where Tickets are planned entities, not on a single repository. And issues are single items on repositories. I can see people who make software in public, wanting to have a project planning seperated from their public issues on a repository. And at the same time you could link a ticket to repositories, which would inturn also show it in the issues of a repo.

CI/CD

Every company has CI/CD running through github, or selfhosted but it was all written with the github actions ecosystem. So let’s just keep using that.

Your Github action workflows should work exactly the same in neosource. If it does not it is an issue on our side. There are ofcourse some minute limitations that are impossible / very annoying to shim/bypass, but we will see how bad it gets.

You can also ofcourse use packages. Which is our idea of making ci/cd easier to cache (for us as a runner provider) aswell as a nicer way to write them then using standard images and running apt update && apt install ....

jobs:
  test:
    packages: [go, postgresql]
    # Or
    packages:
      go: "1.24"
      postgresql: "16"
    # Or
    packages: { go: "1.24", postgresql: "16" }
    steps:
      - run: go test ./...

Coming from GitHub Actions should have a proper and updated idea on what you might need to change.

Features that do not cost the platform, do not cost you

This is for sure a bad financial move, but I find it annoying to need to upgrade for features that are literally a:

if user.more_money then feature else bad_feature

So the promise of neosource is that features which do not have a real operating cost, should not cost more for users. Special users and special needs is a different story, but something like ci/cd in merge queue shouldn’t be an enterprise feature…

Some notable things I have seen in my short life:

SAML / Single Sign-On
2FA enforcement
User role management
Branch rules/protection, or ci/cd approval
secret management per environment

If it doesn’t cost that much to create the feature, and it doesn’t cost to operate, it shouldn’t cost the user, voila.