Background story seems to be that a portion of Gitea maintainers formed a for-profit company, and transferred all the trademarks to it, going against former promises made, and blowing up their own community as a consequence. They go over the now-traditional "companies are using our free software without paying us" discourse here: https://blog.gitea.io/2022/10/open-source-sustainment-and-th...
> we’re planning on establishing a fund to be able to provide support to contributors who not only contribute features, but also bug fixes, performance enhancements, and important refactors.
Sounds like any other for-profit company building commercial software. What stopped them from doing that while keeping the original OSS software copyrights intact?
Also curious to see their plan to pay out all the developers working on the OSS that underpins Gitea itself. The list is pretty long.
I will never cease to be surprised when open source developers choose a license that says "Please, please please steal my code and contribute nothing in return" and then act indignant when companies steal their code and contribute nothing in return. If you are starting an open source project, the default license should be the AGPL, with the LGPL coming in second if you just care about making a useful library.
The GPL is not scary. It just provides you the means to enforce what everyone knows is basic decency in Free software: you get total control of the software, in return you release your changes, and provide your downstreams with the same freedom.
The problem is getting a foot in the door. Many companies outright ban AGPL code because their lawyers don't like the obligations (and how they are up for interpretation) that come with it.
That's simply too much friction. There's a reason most projects that see commercial adoption and are AGPL (or SSPL) started out more permissive.
I’m curious about their plan for paying out developers as well.
I have some vague notions for “community supported software”, where features and implementation priorities are driven by the community and not the enterprise. In order to give the developers a fair share, I was thinking of something similar to kickstarter rounds for feature sets, with a defined group of developers for that round.
I’m sure the practical reality is challenging. For example, that means doing fundraising and marketing regularly. There is also an opportunity cost — this is meant to serve the community, and it’s unlikely anyone will get FAANG level compensation for work on this.
Also, reading https://news.ycombinator.com/item?id=34011469 -- such as this article (https://stefan-lesser.com/2020/10/27/how-to-adopt-christophe...) ... I'm getting an inkling that there's something related to Christopher Alexander's ideas on end-user programming that is somehow related to community supported software. That in order to have software designed for community interests and have people involved fairly compensated, it involves end-user programming in some way.
> What stopped them from doing that while keeping the original OSS software copyrights intact?
But the original copyrights and license stay intact, not?
By the way, hard forking always gives a sense of confusion to me. Will both projects have a bright future ahead, or will one of them fall by the wayside. Sometimes it takes a few years to crystallize, like with ffmpeg/libav.
I do understand Codeberg has ambitions and a place in the FOSS ecosystem (that is why I moved to it), I just hope it all pans out and they don't bite off a bite that is too big. No idea about Gitea, as I wasn't directly involved. They seem to go somewhat towards a RedHat model, offering support for money. It might be that if Forgejo will really take off and builds a community, Gitea will base off of Forgejo in some future scenario.
> By the way, hard forking always gives a sense of confusion to me. Will both projects have a bright future ahead, or will one of them fall by the wayside. Sometimes it takes a few years to crystallize, like with ffmpeg/libav.
Countless examples either way. It can lead to a "nodejs/iojs" situation where the fork happened because of disagreement, and the upstream project realizes their mistake and eventually integrates the fork into mainline development repository. That probably would count as a success for everyone.
Or it goes the way of webkit/blink, where both forks are successful in their own way, although the project they forked from (khtml), probably is considered less successful.
Either way, that it's even possible to fork and continue working on both I'd consider a success in it's own way. It's the beauty of FOSS.
Maybe the best fork win, and also the base it was forked from.
> that it's even possible to fork and continue working on both I'd consider a success in it's own way
I totally agree.
We can be upset that the Gitea people choose to profit personally on the brand, causing a hard fork, but the beauty born from the ashes is priceless: A new hard fork shakes things up, brings new initiative, people jumping in and saying they'd like to contribute.
There are other examples of forks where each direction is doing its own thing.
HackMD -> HackMD -> CodiMD -> HedgeDoc is another example. I believe they're all alive.
I believe Gogs, from which Gitea once forked, is still being developed on.
It is a healthy sign that this software is already so good that even if you hardfork and lose easy access to the advances made in the sibling branches, you probably don't need it, because the basics are there.
Possibly, yeah. Although Codeberg was already sort of similar, they had patches on top of Gitea, so assuming it doesn't change too drastically it may stay feasible for quite a while.
They do say "The Gitea project will of course remain open source, and a community project."
It's not clear to me if they intend to further develop Gitea or work on the non open parts. Looking at the reactions and the announcement it looks like everyone assumes the latter.
Because this is how GitLab did it. Started with open source w/ closed parts, then progressively hid source and ways to download and install GitLab on your own infrastructure.
Currently (as I checked 30 seconds ago), downloading and installing is easy, but finding the small "Install" text on the bottom of the page is not. You need to further dig the docs to find the location of the source in the webpage, too.
Everybody assumes that Gitea took the first step towards this state, and they are right to assume that, because we have no other prominent examples.
Which website did you open to download and install GitLab? about.gitlab.com > Resources > Install provides an overview of all distributions and installation methods (packages, cloud native, etc.) at [0]
> You need to further dig the docs to find the location of the source in the webpage, too.
I assume that the intention was to download GitLab's source code and start the installation from there?
The recommended way to install GitLab is through packages and cloud-native deployments. There are many components involved in the architecture [1], and these methods also help ensure that (database) migrations are run as intended, keeping upgrade maintenance short. Installing from sources is not recommended, albeit possible.
The source code is available for both, open source (CE) and source available (EE), following GitLab's stewardship promise [3].
Maybe this needs an update for the website, please let us know.
First, I want to note that the comment didn't meant to take a jab at GitLab. I'm administering self-hosted GitLab on two installations for a decade now, and had no problems with it. Actually, I wanted to move to GitLab when I decided to leave GitHub, but, Source Hut fits my needs better.
I went to "www.gitlab.com", which sent me to "about.gitlab.com". I scanned the page, and looked to solutions first, expecting to see "Self Hosted", not seeing it, I clicked to Pricing, where I failed to see Self-managed install. Possibly frustrated, scrolled down and found the "Install" link.
I remember peeking at Resources menu, too but I looked to the first three or so entries possibly. I chalk the situation to a bona fide PEBKAC + Friday tiredness.
> I assume that the intention was to download GitLab's source code and start the installation from there?
Actually no. I trust to a codebase which I'm using for a decade. In most cases, I try to find the code repository to look at the licenses, code organization, or to see how something works. In this case I wanted to do the same (see the licenses, and find the repo in general). I expected to find a direct link to the source code repository. This case was the same. I just want to see the code, and take a look around.
Being able to find the source code repository only via documentation, at least for me, sends the message of "The code is there, but we actually don't want you to see/access it so easily, unless you really want to".
> The source code is available for both, open source (CE) and source available (EE), following GitLab's stewardship promise.
I didn't know that EE was source available. I'm adding this as a plus to my mental notebook, and honestly thanks for being like this.
All in all, I understand (and deeply respect) GitLab for being what it is. I witnessed it becoming from a GitHub clone(ish) to a CI/CD first development platform. I possibly wanted to be greeted by a more developer-oriented webpage than a customer-oriented one, but I guess this works well for you, so I have no complaints.
Thanks for directly answering my comment, and filling the gaps in my knowledge. I really, greatly appreciate it.
I "recommend" you work on making the install process better then. There are projects bigger and more complex than gitlab that don't have any trouble with installing from source.
It also has contributor benefits: if I can't build the repo into a working state, I can't contribute fixes. That's jammed me up with GitLab at least 3 different times now where I've opened issues that I'm perfectly capable of fixing, but since I'm not a battle-hardened Rubyist, and gdk is both some whatthehell and also dies mysteriously, those issues just lie on the pile with the other 46,000
The current plan, as far as I know it, is to continue on the OSS part predominantly.
The only parts that would not be, would be anything that comes from a contract and doesn't make sense to contribute back.
For example, if a company wants some bespoke functionality that doesn't make sense in the main repo.
It is great that Codeberg has taken custody of the Forgejo project, and will use it for their own services. Not only is Forgejo using exclusively FOSS tools now, maybe the additional services that Codeberg offers, like Codeberg Pages, Codeberg CI (based on Woodpecker, FOSS Drone.io alternative) and Translations (based on Weblate) will become very easy integrations to any Forgejo installation.
There was no drama as far as I recall, just complaints that he wasn't agile enough or something like that. The different project is Gogs https://gogs.io/ and its author is Joe Chen ('unknwon').
From what I recall the drama was that the split was timed to his absence and they announced everywhere that "Gogs is dead/unmaintained" until he came back and set the record straight.
The reason for the split was understandable, them going around proclaiming Gogs dead and unmaintained felt pretty scummy to me, however.
The drama was that the original project's maintainer had full control and would go absent for weeks/months leaving the project in limbo, and refused to share the maintainer burden with anyone (including refusing features he disliked).
> refused to share … (including refusing features he disliked)
That makes the maintainer of Gogs sound rather petty, which I don't think is true. It is their project, they don't have to give control to anyone else if they don't want to, or implement features that they don't want.
A number of projects are explicitly “open source, not open contribution” and this is perfectly OK. If it is a problem for other individuals or “the community” than there is always the fork option (as taken by Gitea and now Forgejo) or if that isn't practical maybe offering to pay the maintainer, so can afford to make time to bother more with needs/wants away from their own (though in the latter case, don't be offended if this is politely rebuffed also).
> and refused to share the maintainer burden with anyone (including refusing features he disliked).
I realize gogs is MIT license which is subject to easy fork. To avoid a fork when using such license, you have few options. One is fully feature your product, the other is expect your product to require domain specific skills that makes fork less trivial to move on; file format, data manipulation, etc.
So I wondered if original maintainer really wanted to avoid the fork, or simply don't care. It would be interesting to hear.
It took a long time, but GitHub has finally (thankfully) shipped privacy settings that allow you to disable the way it broadcasts/publicizes your every move on your profile page. Does Codeberg or Gitea allow this yet? (They really should have been the first to do so...)
It would be nice to also disable the public listing of repositories for your profile page and to control it for organizations, too. (Not talking about private repos. Instead: these should be ordinary repos that remain accessible to anyone who has the link, but they are simply not aggregated into a single unified list that's available to anyone who clicks over to the "Repositories" tab. Think of them like unlisted YouTube videos, except they are all unlisted by default, rather than having to specifically designate each one as being unlisted—although that would work, too, it's just not the way it should be implemented.)
Codeberg is not for private code, it's explicitly for "Free and Open Source Software". Probably it would still make sense to have some privacy for authors/contributors, so you can't simply list all activity by going to someones profile on the website, but the repositories should still be findable, browsable and public, as that's the goal of repositories in the organization Codeberg e.V.
Off-topic, but I'm really amazed that HN account lasted for 2 years. I've seen pwdis accounts before, but they quickly get vandalized and locked out. Is this a lucky account, or is there a mod intervention?
Edit: oh wait, never mind, the profile does confirm that dang is involved. Interesting stuffs.
> Throwaway accounts are ok for sensitive information, but please don't create accounts routinely. HN is a community—users should have an identity that others can relate to.
I don't think shared accounts violates the guidelines since no accounts are routinely created from sharing it. Having an identity to relate seems to be an ideal preference, but not a hard requirement. Some people do routinely create new accounts anyway to avoid fingerprinting writing styles.
Anyway, shared accounts are interesting because it's a hack on the signin system to allow a more anonymous posting. It reminds of Stallman's aversion to password in the early days, and repeats his login ID as his password.[0]
1. What can you point to that explains or even suggests that repos "should [...] be findable" directly on codeberg.org and for "people browsing [it] and pages within"? E.g. that creating an unlisted repo and then setting up a publicly facing project landing page/mailing list/etc. that independently refers potential contributors to the repo but doesn't make available a top-level index of all such (possibly unrelated) repos that a given person controls, is something that would run afoul of either Codeberg's policies or goals.
2. What is your relationship to the Codeberg e.V. organization?
I'd suggest you read their ToS[0], specifically section 2.1(.2). It shows that they'd really like you to make all content public. To guarantee that publicity, they rake care of the listing. There is (currently?) no option for unlisted repos. just either public or private. And by the observing the way they think about privare repos, you can form an idea about how they'd think about unlisted repos.
I've read that. It doesn't say or even suggest anything like what we're actually talking about here. Someone pointing to those terms in the TOS is either confused about what this discussion is about, confused about what exactly the TOS is addressing, or both.
> 1. What can you point to that explains or even suggests that repos "should [...] be findable" directly on codeberg.org and for "people browsing [it] and pages within"? E.g. that creating an unlisted repo and then setting up a publicly facing project landing page/mailing list/etc. that independently refers potential contributors to the repo but doesn't make available a top-level index of all such (possibly unrelated) repos that a given person controls, is something that would run afoul of either Codeberg's policies or goals.
Here is some resources directly from Codeberg.org to explain the position:
> Codeberg is a collaboration platform and Git hosting for Free and Open Source Software, content and projects.
> Private repositories are only allowed for things required for FLOSS projects, like storing secrets, team-internal discussions or hiding projects from the public until they're ready for usage and/or contribution.
> Since this is not what Codeberg is meant for in a more narrow sense, stricter limitations might be implemented in the future.
> The mission of Codeberg e.V. is to build and maintain a free collaboration platform for creating, archiving, and preserving code and to document its development process.
> [2] (1) The purpose of the association is to promote the creation, collection, distribution and preservation of Free Content (Open Content, Free Cultural Works) and Free and Open Source Software (FOSS)
> [2] (2) For the collection and distribution of free content, open and commonly used Repository and Version Control Systems ("RCS" and "VCS") that save and preserve the whole history of the creation and improvement of Open Source software and make it freely available to society on the Internet, should be primarily but not exclusively used and generally made available.
1. Dodging the question with non-answers that conflate unlisted repos and better account privacy settings with the stuff that is known to be forbidden on Codeberg does no one any favors. It is no surprise that repos for non-free software and private repos for general use are not allowed. Where is the part that's relevant to what was asked?
2. Someone who was wondering whether I'd made a huge mistake by moving stuff there a year or two ago and whether I should know something about the folks behind it that would indicate that I should reverse that decision, not support it, and not recommend it (alternatively: advise against) in the future.
For anyone else who, like me, couldn't decide which pronunciation it was the FAQ says "(pronounced /forˈd͡ʒe.jo/)". I don't know IPA so I can't tell if that j in ".jo" is like "joker" or like the french "jambon" or if it's soft like "yo"
It's a mistranscription of the Esperanto word forĝejo, meaning "forge" (i.e. the place where forging happens).
But diacritic marks aren't optional in Esperanto, they change pronunciation and meaning. "Forgejo", which is pronounced with a hard "g" (IPA /g/), is a nonsense word which means something like "distant gay".
The correct transcription without diacritics would be "forghejo".
I missed that they called this out specifically on the announcement page; I appreciate they acknowledge the source. Wonder why they didn't then go for the .io domain possibility with "Forgeio".
There's a controversy with regards to the .io TLD. Especially on the Fediverse people using this TLD are often reminded of this and discouraged to use it.
As a German proficient in English that name just makes my head hurt, no matter how the real pronunciation is. Maybe I'll go with a combination of Jorge and rojo (in Spanish) out of spite...
Also, missed opportunity, Codeberg folks. Why Not "Erika"? ;)
> Also, missed opportunity, Codeberg folks. Why Not "Erika"? ;)
Oh wow, that's a deep cut. I'm deeply impressed and amused. Almost to the point of yodeling ;)
(For those lucky enough not to be this old and/or German, there once were two sisters called "Gitti & Erika" who made some horrible, yet famous Schlager songs – folksy chansons. Including the title melody of the local dub of the "Heidi" anime, triggering basically every "80s/90s kid".)
I think it's male name -> female name -> flower named after that -> song named after that. I honestly doubt that that's the first thing that comes to mind and thus would besmirch the good name of, erm, git. ;)
(Not that I'm suggesting actually naming something after a boomer-level German in-joke in the first place.)
> we’re planning on establishing a fund to be able to provide support to contributors who not only contribute features, but also bug fixes, performance enhancements, and important refactors.
Sounds like any other for-profit company building commercial software. What stopped them from doing that while keeping the original OSS software copyrights intact?
Also curious to see their plan to pay out all the developers working on the OSS that underpins Gitea itself. The list is pretty long.