Moving Away From Github

I’ve been a loyal user of GitHub for as long as I can remember, and for the most part, I’ve had a positive experience. However, lately, I’ve found myself questioning the direction in which the platform is heading, and I’m uncertain if it still aligns with my needs. While there are many features that I appreciate, I’ve noticed a shift in focus towards enterprise and commercial endeavors, particularly with the introduction of Copilot and code spaces.

These developments suggest a pivot towards catering more to corporate clients rather than prioritizing support for the open-source community, which has traditionally been GitHub’s stronghold. While I understand the need for growth and diversification, this shift in focus has left me contemplating whether GitHub remains the right platform for me.

Why the Move

I’ve decided to part ways with the platform for two primary reasons. Firstly, the culture has taken a turn towards toxicity, where some users seem to make changes to repositories solely to boost their activity levels, presumably to bolster their chances of landing a role elsewhere. There’s a misguided belief that activity count outweighs actual contributions, leading to an influx of trivial commits like typo fixes and README formatting changes. These actions not only waste the time of repository maintainers, who are often already stretched thin but also foster defensive and gatekeeping behavior within open-source communities.

The second issue revolves around Copilot, an AI tool designed to assist with coding tasks. While Copilot itself isn’t the problem, its training data raises concerns. It has been trained on public repositories from the platform, potentially infringing upon the licenses of the projects and developers due to inadequate attribution of code usage. This issue has even sparked discussions about creating new licenses to prohibit AI training on source code, alongside legal actions¹ being considered. The combination of these cultural and ethical concerns surrounding Copilot’s training data has led me to conclude that it’s time to move on from the platform.

GitLab

In recent times, a significant number of users have migrated to Gitlab.com, the primary platform operated by the company bearing the same name. It offers the open-source Community edition of Gitlab, a favored choice among prominent projects such as Debian and Gnome.

Despite my tenure on Gitlab.com, I’ve encountered various issues that have led me to reassess my commitment. The platform’s user interface, in particular, has proven cumbersome and unintuitive. Furthermore, concerns about its venture capital backing have raised questions about its long-term trajectory.

Additionally, notable incidents have shed light on internal practices, causing further concern. One such incident involved controversy surrounding a reported directive for female employees to wear high heels.²

Codeberg

I’ve recently relocated all my personal source code repositories to Codeberg, a platform that offers a free home for open-source projects. It aligns with the principle that open-source software should have a free and open-source platform to call home. Built on Forgejo, a derivative of Gitea, Codeberg provides a familiar interface for users accustomed to platforms like GitHub.

Managed by Codeberg e.V., a nonprofit organization based in Berlin, the platform’s website outlines its mission, emphasizing its commitment to supporting free and open-source projects. The Codeberg blog archives provide insight into the platform’s growth, challenges faced, and problem-solving strategies employed. Notably, Codeberg offers free hosting for projects with appropriately licensed³ content.

Further Investigation

While exploring Codeberg, I noticed that it doesn’t offer default actions or runners. This means users need to provide their hardware for runners if they want to use actions. Although I see the potential benefit of this feature for future projects, I need to look into it more before deciding.

I also found out that the platform’s Continuous Integration (CI) service is powered by Woodpecker. Woodpecker is a tool that helps automate different stages of software development, like building, testing, and deployment. Access to this CI service requires a formal request, likely to manage the platform’s resources effectively and ensure fair access for all users.

During my exploration, I learned I could host my instance of Woodpecker and connect it to my Codeberg account. This option gives me more flexibility and control over CI processes, which I find appealing. I’m considering this option as I continue working on Codeberg.