5 ms·

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 pro

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-the-future-of-gitea/ 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.

mpol 4y ago
> 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.
- capableweb 4y ago
  > 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.
  - sshine 4y ago
    > 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.
- jolheiser 4y ago
  As a quick clarification, Forgejo is a soft fork, not hard. They will still benefit from upstream contributions.
  - silverwind 4y ago
    There will come a point where the branches have diverged too far and merging becomes infeasible. So long-term, it's bound to become "hard".
    - jolheiser 4y ago
      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.
saghul 4y ago
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. I wonder why not both?
- bayindirh 4y ago
  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. And I tend to agree with them, too.
  - dnsmichi 4y ago
    GitLab team member here. 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. [0] https://about.gitlab.com/install/ https://about.gitlab.com/install/ [1] https://docs.gitlab.com/ee/development/architecture.html https://docs.gitlab.com/ee/development/architecture.html [2] https://gitlab.com/gitlab-org/gitlab https://gitlab.com/gitlab-org/gitlab [3] https://about.gitlab.com/company/stewardship/#promises https://about.gitlab.com/company/stewardship/#promises
hosh 4y ago
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.
- hosh 4y ago
  Also, reading https://news.ycombinator.com/item?id=34011469 https://news.ycombinator.com/item?id=34011469 -- such as this article (https://stefan-lesser.com/2020/10/27/how-to-adopt-christopher-alexanders-ideas-in-the-software-industry/ 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.
OkayPhysicist 4y ago
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.
- jacooper 4y ago
  We need an ALGPL license.
  - wallmountedtv 4y ago
    EUPL?
- _cenw 4y ago
  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.

mpol 4y ago

> 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.

capableweb 4y ago
> 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.
- sshine 4y ago
  > 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.
jolheiser 4y ago
As a quick clarification, Forgejo is a soft fork, not hard. They will still benefit from upstream contributions.
- silverwind 4y ago
  There will come a point where the branches have diverged too far and merging becomes infeasible. So long-term, it's bound to become "hard".
  - jolheiser 4y ago
    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.

saghul 4y ago

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. I wonder why not both?

bayindirh 4y ago
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. And I tend to agree with them, too.
- dnsmichi 4y ago
  GitLab team member here. 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. [0] https://about.gitlab.com/install/ https://about.gitlab.com/install/ [1] https://docs.gitlab.com/ee/development/architecture.html https://docs.gitlab.com/ee/development/architecture.html [2] https://gitlab.com/gitlab-org/gitlab https://gitlab.com/gitlab-org/gitlab [3] https://about.gitlab.com/company/stewardship/#promises https://about.gitlab.com/company/stewardship/#promises

hosh 4y ago

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.

hosh 4y ago
Also, reading https://news.ycombinator.com/item?id=34011469 https://news.ycombinator.com/item?id=34011469 -- such as this article (https://stefan-lesser.com/2020/10/27/how-to-adopt-christopher-alexanders-ideas-in-the-software-industry/ 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.

OkayPhysicist 4y ago

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.

jacooper 4y ago
We need an ALGPL license.
- wallmountedtv 4y ago
  EUPL?
_cenw 4y ago
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.