https://www.coactivate.org/projects/disintermedia/for-profit-freedom-forges
@strypey GitLab is not fully-free, it's freemium / open-core whatever you want to call it. The fully-free community edition is completely usable as is, but there's many valuable features they retain as only "shared source" proprietary.
Unrelated, here's another reference article: https://wiki.snowdrift.coop/market-research/history/software
@wolftune true, and these are the kinds of nuances I'm gathering the list to write about. But for me the key point is:
> The fully-free community edition is completely usable as is
I've also seen them move functions from the EE to the CE after being asked to in Hacker News threads, so they seem pretty genuine about serving the free code community as well as keeping the lights on. My suspicion is that EE users get to play with all the new toys first, but eventually everything migrates into CE.
@strypey Your impression is half-right, half-wrong. I've had conversations with the CEO, been involved in negotiations on these things…
GitLab is sincere about caring about free software and being transparent etc. They want to not sell out (though they did take VC investment).
While some features go from EE to CE, the list of EE features has *grown* not shrunk, and there's no pattern of consistently moving EE features to CE eventually. They may move others, or they may further distinguish…
@wolftune
> the list of EE features has *grown* not shrunk
I'm not saying you're wrong (you heard it from the horses' mouth), but that is consistent with the theory of new features entering via EE before eventually being ported to CE. The downside is that CE isn't as feature-rich as EE at any given time. The upside is that CE is simpler and more mature than EE, which is potentially *better* for self-hosters (although I agree they ought to have the freedom to choose that, not GitLab).
@strypey I know they do NOT have any intent that EE features all eventually filter down to CE. For them, the qualification is whether a feature is useful for smaller or single-person cases. Hence GitLab Pages moving to CE. They very well may move further features as they get convinced that small projects could use them. But their plan has been to continue building enterprise (large teams) features and *keep* them EE.
That said, they *would* free it all if there were no business reason not to.
@wolftune
> they do NOT have any intent that EE features all eventually filter down to CE
Maybe the CEO doesn't but ...
@wolftune
> they *would* free it all if there were no business reason not to.
Is there one? Given the number of companies that make significant money selling hosting and other services around free code they develop (or help develop), including a number in my list? Again, I think there is a "common sense" assumption that revenue grows out of the barrel of a gun (that gun being ARR copyright enforcement). I'd say it isn't true, and arguably was never true (Bill Gates just claimed it was).
The core point is not to credit GitLab with having such a EE to CE pipeline trend or plan. EE *might* eventually get to CE, but it will be only because of systemic shifts in business model and other things. They are *possible*. But it's similar to pushing GitHub to free more of their tech. It's simply NOT a situation where you can describe GitLab as this free-software company that *has* such fully-free aims as is. They aren't there now. They're just *mostly* free.
@strypey As is, GitLab has been adding features that free software projects could use but consistently making more and more of them EE to further build their paywall business model for enterprises.
They justify it from their FS perspective by offering all the EE features to any FS project that hosts directly at GitLab.com.
Incidentally, Snowdrift.coop now has plans to transition to GitLab.com instead of the more-ideal sticking to git.coop or git.framasoft.org or other 100% FLO, CE-hosting…
@strypey no, they will never take away any CE features.
They aren't even adding all new features to EE. They are adding anything that seems enterprisy, i.e. would be useful for teams collaborating, to EE.
Their stated and practiced rule is: if a 1 or 2 person small project really could use a feature, it's CE. If this is about larger teams collaborating and other enterprise-level stuff, it's EE.
100% of the EE to CE moves are based on accepting that a feature fits that definition of the CE box
@strypey so it's much easier to say "I'm just a 1-person project, and I want GitLab Pages" than to argue for having multiple-assignees in CE.
We might convince them that issue *weights* deserve to go to CE… etc.
Their focus is on making CE as great as possible for very small projects and, as much as possible, making CE inadequate for large enterprises to convince them they need the EE stuff.
@strypey that sounds like copyfarleft directions… the only way to give a free license to some and not others is to ask interested parties to contact you. Then, you can say informally, "please share this only with other community projects, even though you can legally do whatever". It all gets messy.
Have both free license and reduce barriers to community adoption and you inevitably make stuff available to proprietary businesses too.
I still think the best compromise is simply AGPL and then using crowdmatching via @snowdrift and enterprise-focused solutions like https://tidelift.com and other approaches to get funding…
I agree, those non-FLO incompatible terms are problematic. I/we support *neither*. But do notice that #CommonsClause and #Copyfarleft are at least different motivations. The former is meant specifically to *encourage* and enable proprietary licensing (while still having FLO something), while the latter is *sometimes* used by those who would like to offer the capitalists nothing at all, not even via a proprietary license.
But either harms the FLO commons we have.