Back

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

@strypey

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…

@wolftune are they moving features from CE to EE? I've never heard of them doing that. As I say, adding all new features to EE first makes sense (within the logic of having EE at all), and I've seen people make a case to them on a public forum that CE needs an EE feature, and then it gets moved there.

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

@wolftune ok, but my impression has been that the boundary between EE and CE is single-team, free code projects vs. multi-team, proprietary projects. After all, there is a relationship between the price they want to charge, and the size of organization that is likely to pay it. A number of large multi-project organizations (like VideoLAN) now self-host GL, and I think GL knows they won't pay for EE (or use gl.com).
https://wiki.p2pfoundation.net/List_of_Community-Hosted_GitLab_Instances

@strypey Right, so there's serious tensions because of these things. Their "enterprise" vs "community" is a *wrong* distinction, it's invalid really. It's misguided. But they don't deserve to be seen as not holding this misguided position. They hold it. We need to get them to change while honoring and respecting all the things they're doing well.

@wolftune fair enough. What if there was a way to issue a free code license only to free code projects, and all proprietary projects had to pay a license, whether using GL's hosting or self-hosting? Making proprietary software companies pay for free code for the community to use would be a clever hack ;)

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

@strypey

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…

@wolftune @snowdrift yes, I agree. The #CommonsClause FAQ does offer a critique of AGPL, but it doesn't seem to me like they're really thought it through at a deep level. #OpenGift and #CoopExchange are other platforms trying to solve the funding issue. I've seen pitches from both at recent conferences. I'm skeptical, but intrigued

@strypey @wolftune @snowdrift Please oppose #CommonsClause and #Copyfarleft for functional data.

@strypey @wolftune @snowdrift Because of this: https://pleroma.apkfission.net/objects/32b0a92a-da9c-4958-887c-d24abc16d458