SUSE reaffirms support for Btrfs

Posted Aug 24, 2017 23:49 UTC (Thu) by ThinkRob (guest, #64513)
In reply to: SUSE reaffirms support for Btrfs by SEJeff
Parent article: SUSE reaffirms support for Btrfs

I don't think it's that inaccurate, personally. I get the business reasons for why they do it, and they have enough of a history of it that we can start to draw some conclusions from their behavior.

I think that from a business standpoint, Redhat wants to make sure that they're never at the mercy of a competitor. So for some tech, that means sponsoring or even "buying" the project (although the latter is probably only useful if they have a CLA).

Really I think it's about Redhat not wanting to build a bunch of stuff on something, only to have Oracle or IBM or whomever swing by five years into a release and buy the project out from under them, then turn around and demand money from Redhat for continued access to patches/source/whatever-other-vital-asset. That would be the nightmare scenario: if Redhat added a major feature into RHEL, had customers build things that depend on it, and then half way through the support period Redhat had to choose between paying royalties to a hostile third party or eating the cost of maintenance of the project. At least "buying" the various projects gives them some budgetary freedom, since presumably there's already a community doing a lot of the heavy lifting. That frees up RH to scale its involvement as it wants, from leadership positions (ala CentOS) to "just fix the things that affect the version we shipped in RHEL."

SUSE reaffirms support for Btrfs

Posted Aug 26, 2017 4:09 UTC (Sat) by gdt (subscriber, #6284) [Link]

When you buy a open-source software company you also get the people. Often the ability to direct the future work of the software team is more important than the software as-is (which, after all, you can ship and modify for free).

Moreover, if you are a vendor offering long-term support of Linux for enterprises you might want to be able to direct the team's urgent attention to a five-year old bug, fixed for years, but which is nevertheless preventing a bank from doing its thing. The ‘community’ in this case is not useful, as their answer is “upgrade”. These occasions are rare, but it is an important capability which allows the software vendor to charge high prices to such enterprises.

SUSE reaffirms support for Btrfs

Posted Aug 28, 2017 15:52 UTC (Mon) by raven667 (subscriber, #5198) [Link] (1 responses)

> At least "buying" the various projects gives them some budgetary freedom, since presumably there's already a community doing a lot of the heavy lifting.

I'm not sure what you mean by this, when Redhat "buys" a project that just means hiring the most productive members of the community, the ones working full-time on the project, so by definition then Redhat is doing the heavy lifting as the majority of the hours put in by the community.

> or whomever swing by five years into a release and buy the project out from under them, then turn around and demand money from Redhat ...
> choose between paying royalties to a hostile third party or eating the cost of maintenance of the project.

If they hire the developers of the project then they are by definition eating the nearly full costs of maintenance for a project, I don't think there is any scenario where Redhat pays royalties as opposed to hiring staff to continue maintenance as they don't ship anything they don't have a clear source license to. I doubt that Redhat ships anything where the bulk of development hours are currently paid for by someone else that they don't have a plan to full development resources on it should the maintainers stop for whatever reason.

SUSE reaffirms support for Btrfs

Posted Sep 1, 2017 0:55 UTC (Fri) by ThinkRob (guest, #64513) [Link]

> I'm not sure what you mean by this, when Redhat "buys" a project that just means hiring the most productive members of the community, the ones working full-time on the project, so by definition then Redhat is doing the heavy lifting as the majority of the hours put in by the community.

Well yeah, but they also benefit from the long tail of contributions.

> If they hire the developers of the project then they are by definition eating the nearly full costs of maintenance for a project, I don't think there is any scenario where Redhat pays royalties as opposed to hiring staff to continue maintenance as they don't ship anything they don't have a clear source license to.

That's true. I suspect I should have been clearer. I think they deliberately try to make sure they *don't* wind up in a position where they'd have to do that, and that this is one way of ensuring it.

SUSE reaffirms support for Btrfs

Posted Aug 28, 2017 19:08 UTC (Mon) by flussence (guest, #85566) [Link]

>That would be the nightmare scenario: if Redhat added a major feature into RHEL, had customers build things that depend on it, and then half way through the support period Redhat had to choose between paying royalties to a hostile third party or eating the cost of maintenance of the project.

Outside the bubble this isn't a hypothetical scenario: people already invest a lot of effort, money and time to defend the wider Linux community against becoming wholly dependent on Redhat projects (including under the fd.o umbrella).

SUSE reaffirms support for Btrfs

Posted Mar 28, 2018 17:32 UTC (Wed) by ceplm (subscriber, #41334) [Link]

At least with BTRFS you have your facts wrong. Josef Bacik was at Red Hat while RHEL was expected to be future default Linux FS. However, BTRFS was dropped on technical reasons (you may agree or not, but that isn't the point), and only then Josef left.