Reading · Daniel Siepmann - Coding is Art - All Blog Posts

Introduction ¶

I've worked with Phabrictor, GitHub, Bitbucket and GitLab in the past. GitHub itself has a very clean process for forks and many people seem to be fine with them. I myself wasn't aware of some issues for a very long time.

But a TYPO3 community member recently contacted me because of a so-called “fork” I had created which changed my mind. That revealed a big issue to me, followed by some smaller issues.

I share this, so you become aware and can judge for yourself whether those issues apply for you as well. And I share this, so you can decide to find other ways in case you develop software like Forgejo.

Concrete issues ¶

A member of the TYPO3 community contacted me because he found a so-called fork for a new TYPO3 extension. I indeed forked the official extension in order to add support for another TYPO3 version. But this was not intended to be a fork. That's what you are forced to in order to contribute a so-called Pull Request on the GitHub.com platform. All I wanted to do is to play around with version support and provide a Patch for discussion. Check with maintainers whether it would make sense to add support for that version.

There is no way to provide a Patch on the GitHub.com platform without being forced to create a fork. You start by creating a fork on that platform where you push your changes allowing you to provide a Pull Request which is more or less the name of the process to contribute changed back to another repository. The thing is that GitHub.com is great in discoverability regarding forks. The member had a look at the Insights tab and found my fork with the supported version.

Another issue is that I can't delete my fork. Well I can, but that would remove my branch and close any Pull Requests related to those branches.

Then there is another issue. You can decide to allow maintainers of upstream repositories to modify your pull request. But a pull request really is another branch, from your downstream repository, compared to a branch in upstream repository. The maintainers indeed now modify your own branch. Making it impossible to use this branch within your projects as it became a moving target outside your control. You no longer own your own code.

The underlying issue ¶

GitHub in general doesn't separate contributions and real forks. They have one concept for everything.

And that looks very much like GitHub itself does not even care about open source contributions.
And having a look at their website right now (2024-03-13) indeed states things like “The world’s leading AI-powered developer platform.”, “a complete dev environment”, “secure code”, “GitHub helps your teams work more efficiently together”, There is nothing about open source or contributing.

There is no way to contribute to open source projects right now, without first creating an account and following their forced workflows creating more and more data by creating forks and following their rules. Putting more contributions into their AI.

Workarounds ¶

I am only aware of a single possible workaround right now: I could upload a patch file within an issue for discussion. But that would remove all the benefits of a PR where you can discuss and comment on the actual diff, see whether the CI still passes (e.g. whether I would break existing compatibility). That isn't a workaround to overcome contributing to Microsoft and creating an account.

The only real workaround seems to be to find some email and send a patch there, hoping for the best. And that one will not be visible to others, exposing your solution to build on.

Proposals ¶

I would love to see a way to create hidden forks only for contributions. Those wouldn't be exposed anywhere and only be used for the pull request itself. One hidden fork per pull request in case you create multiple requests. They should also not prevent you from creating repositories with names you like.
Or even better upload patches to start a pull request workflow, without the need to have an account. Other tools like Gerrit work that way. They only work on patches compared to the target. There is no fork.

Conclusion ¶

I now have a better understanding why Linux Kernel is still developed via E-Mail patches and a mailing list. It doesn't have the downsides of GitHub.com that probably apply 1:1 to any other platform more or less.

It is a shame that we didn't overcome those issues yet and that we don't have a proper platform for hosting and working on open source projects in 2024. I hope projects like Forgejo will help to overcome those issues in the future.

Issues with GitHub Fork process