Maintaining your own fork is a ton of work. Even if it's just routinely rebasing on upstream and maintaining your own upgrade infrastructure and doing releases, that's far from trivial.
The open source community really needs to stop with the "just fork it" mindset.
> Maintaining your own fork is a ton of work. Even if it's just routinely rebasing on upstream and maintaining your own upgrade infrastructure and doing releases, that's far from trivial.
Well I did it for Mattermost and for some other software as well. Sure, its some work, but it's not "a ton" of work and may not be "trivial" but it is also not "far" from trivial.
Do it like Linux maintainers maintain a ton of patched RPM's, deb's, etc. Just keep a patch in GIT. For every release of Mattermost you do a GIT clone, apply your patch and build it. Most of the time the patch will just apply cleanly. Sometimes you need to make a few adjustments, you make them and put them in GIT. There is no extensive release management or anything. You just build a patched version for every released version.
> The open source community really needs to stop with the "just fork it" mindset.
It's right mindset. Just not applicable to projects that are made majority by the company because none of the contributors will move so it's essentially trying to make new team from scratch.
I don't think the implication is that anyone as an individual would fork it.
I think the implication is that some other interested org could very easily step in and assume the role that the Mattermost org was in, and everyone would very eagerly switch and leave Mattermost itself speaking to an empty room.
>The open source community really needs to stop with the "just fork it" mindset.
The open source community really needs to stop with the "just do everything i want for free" mindset.
I mean, open source does not mean you're entitled to free support, and free in free software is not about money. I think people depend too much on those projects and then act entitled.
Of course the open source bait and switch done by companies is a shitty behavior worth calling out, but the companies exist to earn money and at this point this can be expected.
From my observation Mattermost is not a software you buy "support" for. It either works and is self-manageable or you use something else. I guess Mattermost (as in the company) saw that too and now uses shitty practices to coerece people into buying it.
I don't think I've expressed a "just do everything I want for free" mindset. In fact, I'm pushing against the idea that someone should just fork Mattermost and maintain that fork for free.
I do think this development represents a bait and switch though.
I use MM for about a year. Forking it would be a major undertaking as the number of vulnerabilities for which you would need to backport is quite high like 5 a month?). Last time they removed features from free (group calls in v10) there was a lot of grumbling but thats it.
Maintaining a patch set for Mattermost is almost trivial. I did it for several years to authenticate users to internal Active Directory and found it easy enough to understand.
Nothing. Open Source is dying. The model to finance open source work (well-off suburban american dads or as a portfolio show off) no longer apply. The old generation that believed in this model is retiring and for the new generation it pays better to "network", leet code, or spam your resume to thousands of employers.
Now couple that with the fact that supply-chain control is profitable (legally or illegally); I think the next 5-10 years will be interesting.
There never was a model to fund open source. At least outside largest and most wide spread codebases. I think it is that reality is finally hitting. Free money has run out and now software must stand as either community efforts, wide enough used foundations or forced support.
glancing through the code, it doesn't seem like it be that hard to remove limitations such as this. PostHistoryLimit/postHistoryLimit interpreted from License Limits. a little poke here and there and I'd guess the limitations would disappear.
The time and energy that it takes to do it and build it, and then make it easy for current users to move their automatic updates to the fork, then maintaining it etc.
AGPL and Apache are both open source licenses. So I’m not getting what the confusion would be as an end user, who won’t be modifying the software or packaging it for sale.
Combining source code under different licenses into one product is a nightmare.
You have to follow the AGPL "no additional restrictions" clause while also following the Apache License, and the Apache License might have require you to follow additional restrictions.
Honestly this has never been an issue for me, sure I have had to explain the limits of the licenses and check that I understand them. I guess it depends on your use case, so I am still uncertain when this has become a problem for you.
