> One way that open source companies are doing this model to fantastic effect is by open sourcing their upstream and creating a cloud distribution (read: managed service). A variety of companies have embraced this model to greater or lesser extents.
COSS is the emerging Business model, and helps entrepreneur take the best from Open-source and Cloud
I see references everywhere (including this article) that the "co-founder of CentOS started a new distribution: Rocky Linux".
I am not familiar with the history of CentOS, so I tried to understand who Gregory Kurtzer is, and to be honest, I am still not quite sure what he did for CentOS.
My understanding is that he helped start the project and more or less helped it grow during the first 2 years, then was somehow removed from the leading board?
Greg Kurtzer has done a lot of other stuff since leaving CentOS though, mostly in the HPC sphere. He worked at Lawrence Berkeley lab and started Warewulf for cluster admin. He started Singularity (basically Docker for HPC).
I mean, it's on wikipedia: "Prior to becoming known under its current name, CentOS originated as a build of CAOS Linux, which was started by Gregory Kurtzer." There are a bunch of items on Distrowatch about caos, going all the way back to 2004, like https://distrowatch.com/?newsid=02134 that qualifies him as "the leader of cAos Foundation of cAos and CentOS fame".
It seems clear from a quick googling that Greg started the project; once Rocky McGough entered the picture, Greg handed him the technical reins while he "continued to manage the project, community, and governance side of things", until he moved on.
(Side note: Distrowatch is one of the unsung pillars of the Linux ecosystem. For all its drawbacks, it has run for almost 20 years, and still works fine as a quick way to survey the field of Linux distributions.)
> That’s the strategy. That’s the magic. You don’t need to go Open Core or any other permutation of kind-of, sort-of open source. You can open source everything and just ensure you have a rock-solid managed cloud service. This reliance on cloud is what’s driving MongoDB, Confluent, DataStax, Redis Labs, and others to great success. It can be your model, too.
It's not clear how this would work with a Linux distribution that has already been commoditized by the cloud vendors. Amazon Linux is a CentOS rebrand, and probably soon Amazon Linux will stand on its own feet similar to ElasticSearch, thanks to the Red Hat move
AL2 doesn’t map up to a single version of CentOS already and Amazon would probably be happy to move to being upstream of RHEL for the sake of their kernel team.
Note AWS has a known limited set of hardware. While they do allow install of Amazon Linux outside AWS, that isn’t core to the business or product.
> Note AWS has a known limited set of hardware. While they do allow install of Amazon Linux outside AWS, that isn’t core to the business or product.
Amazon Linux outside of Amazon is purely to facilitate local build and test pipelines, both of which are meant to encourage AWS deployments. They don’t directly make money off it.
Yes, the issue isn't that people want another Red Hat family ecosystem distro. That want one that (nearly) exactly mirrors a specific RHEL point release plus major bug and security patches backports.
I tend to agree. However, there are some very, very large clients out there who have the resources and expertise to run open-source themselves.
This level of enterprise customer is a tough nut to crack because of the infrastructure monolith that lives inside.
Perhaps they might spend the money for professional services or something in their private cloud, but that money is peanuts compared to the valued created by the free software.
> I tend to agree. However, there are some very, very large clients out there who have the resources…
As far as my business experience goes, I would say this is what can make such a system: your sales force. Have a very good sales team that lands a couple of large key clients early.
Yes, it is still the case after +30 years old web and a +10 years old iPhone: the buying decisions include a myriad of reasons, many of them non-technological. A good sales expert can slash through that.
So, yeah, courageous and good management can make it. Specially in a case like this, were it is not necessary to make a paradigm shift in innovation happen. Here we have a player who just needs to box himself onto the table and keep dancing.
A good salesperson flagged with sales-engineers and professional services, but they will be ham-strung by their product roadmap, and the roadmap of the cloud-services they deploy into.
Now you have two problems.
The vendor, and the vendor's vendor, who is (cloud provider). There will be resource limits, VPC peering limits (1g, 10G , 100G), and a myriad of other things that subtly change how deals are done and the donuts are made.
Then, when clients are big enough, these vendors quickly begin to offer bespoke solutions which, again, subtly change how they operate and do business.
This creates friction at all levels because we now have classical bespoke enterprise solutions inside "uniformed" scalable cloud solutions.
We might have just as well stayed in place and expanded in our own data center, run it ourselves in the compute cloud, or in some smaller cases, just buy the company we wanted to do business with.
Works until a big cloud vendor or someone with more funding clones it and takes all the revenue. This is why MongoDB uses an AGPL-like license and CockroachDB uses BSL. Forget what license Redis uses but it’s similar I think.
Redis Labs seems an odd inclusion: they specifically have a non-oss version that’s got significant features not available in the oss version.
It seems hard to believe their success could be attributed to “a hosted cloud service” given that the core product didn’t even support TLS or SSL natively until this past year.
I think the problem is more related to the skilleset of the blog owner, which may not necessarily be in devops but instead economics or journalism or other (tough to say without being able to acess the content).
It's a feature not a bug that we all have different skills. I certainly do not want to discourage others from sharing their opinions due to technical issues that could be resolved more easily by developers (through their implementation and documentation) as much if not more than end users in a given situation.
Yeah, adding a little bit of caching (at least as WordPress plugin without dependencies for external entities) is now the DevOps problem that requires the DevOps solution, nice.
Well, I mean, you can front the blog with Cloudflare using their wizard for free without any technical knowledge. What kind of DevOps magic do you need there?
Maybe changing the default settings based on user experience, or the implementation of a caching layer of some sort for infrequently changing blogs posts (seems that could be the majority) or making the importance of these settings more accessible to the people who use them and aren't developers in layman's terms. I don't use WordPress or blog personally.
I do imagine that this particular issue is causing the author of the post anxiety due to it's unforseen (to them) failure. I'd prefer the computer not discourage them.
According to their own description: "Planet Storyline is a website, which provides you information about Technology, DigitalMarketing, Graphicdesign and more about Lifestyle Blogs." so it's more than a random human studies researcher lacking tech skills.
As @pepemon points out, the free tier of CloudFlare is probably sufficient and most of the non-tech people running their own variant of WP I know of stopped after being attacked (successfully...) by bots at some point. If you lack tech skills, I think it's best to go to wix, squarespace etc. anyway but platforms are definitely not a requirement and you'd be surprised by the amount of (again non-tech) people who can learn to use a static site generator (with premade theme) and host it using vercel or even S3. At some point, if you want to spread a message, it's worth learning how to do it.
I don't understand why RH don't just allow downloading RH for free like they used to. They tried to funnel non-enterprise types into Fedora - it obviously doesn't work for everyone. There always be an Amazon Linux, Oracle Linux, Scientific or CENTOS, which are not improving RHELs brand.
The announcement hinted that that was the plan, to expand the developer program to cover cases like dev/staging servers that don't need active support.
Personal opinion: They shouldn't have announced anything until those plans were ready, it would save everyone a lot of headaches.
Why not just create Red Hat Live or something less confusing and disruptive to existing users? Perhaps upsetting people and making the news is part of the goal.
Long-lived forks are few and far between. RH might be betting on the fact that the ecosystem is effectively not as lively or motivated as it was in the ‘00s. In the worst case, they gain a few months while a solid alternative emerges, and a few years before it can match CentOS’s reputation. The strength of CentOS was its longevity, that made it a credible option for reliable long-term production deployment; it takes time to rebuild that level of trust from scratch, and people who have been burnt once will now be twice shy to go with a community project rather than paying RH.
Almost everyone I knew who used CentOS was doing so because they were targeting RHEL but didn’t want to buy RHEL licenses for everything (e.g. run RHEL on production servers & CentOS everywhere else). If you didn’t want a close to RHEL experience, you’d likely go with Debian to get more packages and a truly open community.
One way of looking at that is to see CentOS as a gateway into the RHEL world, and especially a way for people to get experience with it or test open source software on it. I think that viewpoint just lost out to the other one seeing every CentOS install at a company as lost revenue. That’s not entirely unfounded but I suspect it will produce less revenue and cost them more in network effects than they anticipated. Any open source project, for example, has just been told that they need pay to test Red Hat compatibility.
Stallman was already right, we will never have freedom as long as we use closed sourced software. How can you believe in promises that cannot be validated ?
OSS is an important part of hardware ownership. If I cannot control the software running on my device do I really own the device? If I do not fully control the hardware and software of my devices my ability to participate in the Information Age is limited.
OSS is an important aspect of being a free citizen in the Information Age.
> If I cannot control the software running on my device do I really own the device?
I think that depends on what you mean by "control" and "really own".
Recently folks were complaining that Apple is acting as a monopoly because you can't install a non-Safari browser. Of course they're still stuck installing from the app store. So, demand installing from outside the app store, and they're still stuck using iOS. Demand changing the OS, and they're still stuck using Broadcom chips and indirectly supporting the CCP.
These are all degrees of control, with associated trade-offs. Being able to easily alter and recompile an application is just one degree of control. There are many others you still won't have until you can fabricate a device from raw materials. And even then maybe your government won't allow you to access the necessary designs and materials (enforced by men with guns).
Ultimately, everything is a package deal, and there is really no such thing as "owning" nor "full control", there are just contracts. For example, no one "really owns" their home; they rent the land from the government and (for most folks) the bank.
> my ability to participate in the Information Age is limited
Indeed, because that system works for its own purposes, not for you. You must conform to it, not vice versa. [1]
The problem here is Linux users, not GPL desktop software. Linux users are technical and skint; they have no problem compiling something from scratch if it can save them a few dollars. GPL desktop software would probably fare better on Windows, ironically, where compiling and installing things correctly is nontrivial even for power-users. This is actually becoming even more the case, now that security is getting more and more important: having a known-safe installable build from a trusted party is extremely valuable.
I think that's how Krita (a painting app) pays the bills. The code is GPL, and most Linux distros package it for free. But on the windows store, they have a for pay version for some relatively low price (€25 or such). It's not a billion dollar business like Photoshop, but apparently it pays the salary for a few full time employees.
This is an interesting challenge. But, up until today, the problem is, except for maybe Firefox, there is no GPL desktop software, that is good enough to get sold, regardless of licence.
(No, the GIMP is not good enough to do professional graphic design work. Etc etc pp)
Blender and Krita come to my mind in term of professional graphic applications. There is also other professional software like Ardour for music production or LibreOffice for word processing.
Krita is good software, but it is lacking usability. How could I sell ist against Acorn or Pixelmator? The latter is at 20$ and has superior benchmarks due to M1 support. It is available for the Mac and the iPad as well. It has the perfect UI, whereas Krita has a UI that would weird out everyone who learned graphics in the "Adobe" school.
LibreOffice, you probably know that Excel is one of the biggest software platforms out there. So, I can see a chance here, when you sell script/macro development, but I wouldn't know why anyone would want LibreOffice. It's just in use because nothing else is available on Linux.
Blender is probably very good, but people who need such stuff don't necessarily look too much on price. Performance is more important there.
I don't know enough about music production to comment on Ardour.
I did not comment on Blender as a software other than indicating that I do not know it well enough. I commented about the market for this category of software.
What I said about Krita is true. I think you don't understand that market and it's priorities and thus gained a wrong impression of the meaning of my words.
I think what people mean when they say GPL-licensed software business does not work is not that GPL denies charging in any legal manner but that it's very hard to deny free of charge use while protecting freedom of use. And if you don't deny free of charge use, you will have hard time doing business. Many enterprises (all?) have a procurement process which requires to look for a cheaper or a free alternative. If you provide Mongo under AGPL, it will be harder to get a company to buy a subscription. Procurement officer will nag you with questions why should we pay if there is a free alternative (that's what you call market cannibalization)? Support is the thing that usually gets a procurement through but that effectively cancels all the "unicorn" growth (if most revenues come from support contracts as opposed to licenses) and essentially puts you outside the "blue ocean" because human support does not scale as software can.
Edit: someone mentioned AWS Linux and k8s below, I think it's really off in business terms. Those things are open and free in order to "commoditize the complement" https://www.gwern.net/Complement
>Procurement officer will nag you with questions why should we pay if there is a free alternative (that's what you call market cannibalization)?
Because their legal department prohibits them from running AGPL code :). That's a side reason for non-standard open source licenses I suspect. The hassle of getting legal to approve them is more than the cost of just paying for a commercial license.
No, I was saying that procurement will tell you to use Mongo under AGPL (the free alternative) and not to embed it in the app (if you can). What I meant is that procurement takes OSS-licensed code as a "given" and carefully considers what they get on top of the base product when they pay money (while developers often think that they are charging for the whole thing, but in "enterprise" context). And that is where the blue ocean ends. Independent of that, you are completely right that most serious companies view non-standard free/"free" licenses as commercial and simply consider those as non-OSS products just like they would otherwise.
Maybe there's another perspective on RedHat's backtracking on CentOS I've not thought about before: that they feel like they do/pay all the hard work when AMZN and others just rebrand RH/CentOS, add their proprietary bits, and merely supply a VM (AMI) image. So they basically want to go after AWS, Azure, Google as customers; just like Google wanted those other cloud providers to contribute to k8s a year or two ago.
That would be a pretty rich attitude of them to take if this case. It’s not like RHEL is developed from scratch.
At least 90% of the products value is tied to the Linux kernel itself. The majority of which comes from development effort outside Red Hat. (How many customers would stay if IBM hypothetically kept the userland and swapped to an AIX kernel?)
true for the components, but not for all of the low-level integration work needed to bundle/assemble these, and all of the development/integration of the installers, etc.
there's a reason people use linux distros over building their own
RHEL's only real value is the looong support cycle. (And CentOS was the gateway drug, and now probably someone at IBM, beancounter or VP of sales, or someone with an ideology about how to convert free users into paying customers thought that many current CentOS users will just buy RHEL if they really need RHEL7/8. And ... it's hard to think they won't. The "vendor lock-in" happened the moment they picked CentOS instead of Debian/Ubuntu.)
The low-level integration is just as good in Debian/Ubuntu land too. Hell, Arch does it too pretty well. (There's an announcement list about manual updates, it's worth subscribing to even if you don't use arch[0], because usually the same change will percolate down on the grapevine and next releases of other distros will also change similarly.)
No questions about that. And were I operating something that critical I'd feel good about paying to International-RHEL-Machines for support, they have great engineers.
But at the same time there are many other ways to get really competent support. Of course not for their frankenkernel. But again, were I operating something critical I would likely want to budget for regular updates that support newer HW/firmware/kernel/libc ... but we all know that certifying all that is much more expensive than just occasionally running yum upgrade. ¯\_(ツ)_/¯
Even if 90% of the product’s value was the Linux kernel (which I disagree with but I won’t get into it), the massive value that Red Hat adds to the kernel is a stable ABI for 10 years. Fixes and new features have to be meticulously backported while maintaining compatibility and stability. So yes, it’s community code, but with a huge amount of release engineering to get it to an “enterprise”-ready state.
As of the most recent analysis that I've been able to find [0] (2018), Red Hat was the #1 most active corporate contributor to the kernel (drivers excluded - Intel and AMD do a lot of support for their own hardware), IBM was #2, and Amazon isn't even on the list.
And while I can't find any statistics on contribution breakdowns for GCC, glibc, Xorg, Mesa, Grub2, and other important pieces of the ecosystem, Red Hat does a lot of maintenance and development work outside of the kernel as well.
* Pipewire (Wim Taymans)
* RADV Mesa Vulkan Driver (David Arlie)
* Firefox Wayland support + hardware acceleration support + GCC compilation validation (Martin Stránský)
* The plurality of GCC and Glibc and (until recently) Xorg maintainers
This is exactly why I use Red Hat software. Its the insurance provided by the fact RH engineers are massive contributors to the Linux ecosystem as a whole.
The same problem (from the commercial distros point of view) exists for RedHat now, and anyone following the plan of this article.
If the software you are trying to sell, is GPL, then anyone can do the same as CentOS at any time.
The article suggests users will arrange into two groups, non-paying users of the develelopment version and paying customers of the production-class version.
But the production version is still GPL and so anyone can get the production version for free any time they want.
Your only option for getting out of that is not to use any GPL software in your super valuable commercial product.
That is the GPL deal, which you don't have take. You can take it OR leave it.
What RedHat seems to have forgotten was 2 things, which I'm sure they knew very well at some point:
- Even non-paying users are more valuable to you as non-paying members of your ecosystem than members of any of your competitors. They are actually what keeps your ecosystem a defacto standard. It is incalculable how valuable it is to be a defacto standard for anything.
- Those non-paying users were never and are never going to be paying customers no matter what else you do. Their use is not "lost revenue" because you were never going to get any revenue from them anyway. If they couldn't use your product for free, they'd just use someone else's product for free. There is no "convert them into paying customers".
And there is also no "convert them into development version users" either because of see above re GPL.
All it is is annoying for everyone, even bystanders, that they keep trying.
> But the production version is still GPL and so anyone can get the production version for free any time they want.
That's not correct. Anyone who is already a user can. If you restrict distribution of the binaries, you also restrict the amount of people who can get the sources. You cannot impose NDAs or the likes, but you can introduce some restrictions on their overall privileges going forward (i.e. you republish sources? No more patches or support for you - which is basically what RH does with their paying customers).
RH could stop publishing sources entirely, if they really wanted to, and just provide them to paying customers on request. They don't do that because it's a nuclear option that would effectively push them out of the Linux ecosystem they've invested so much into dominating (RH is effectively the one company who can steer massive amounts of the Linux ecosystem on its own - as shown by systemd et al).
wow. this exact argument is used against persecution of torrenters among others. i seek stuff like torrents because i cannot afford buying and that is the reality for most of the world. simply counting downloads of a song times $.99 is not true.
if i had the money to pay for netflix, i would rather spend 9 bucks than muck around in torrents, hosting sites, ads, malware, etc etc.
>Even non-paying users are more valuable to you as non-paying members of your ecosystem than members of any of your competitors.
This is only true if paying customers aren't constantly transitioning to become non-paying members, because CentOS is "official" and "just as good as RHEL" in every respect including the length of support.
That is what I thought as well then I immediately thought about how the people who make custom Android ROMs (and Windows PPC roms before that) are known as 'Chefs' because they are cooking together all of the different pieces that make their ROM unique. No different than someone cobbling together a linux distribution but Jonathan Carter, of Debian, isn't referred to as a Chef.
The title should read though, "Cofounder of Chef on Centos being open source."
Chef, like Puppet, is used to manage server configurations.
Open Source is not a magic solution. There are plenty of "open source" projects run by a corporation that are a shit-show because they put the corporations' interests first.
Honestly, screw everyone that uses some annoying "Open Source unless you compete with me" license, or doesn't include non-corporate engineers on an oversight board for the project. I don't give a crap if your code is available if you never accept the PRs that I make, or never address the issues I raise. Often these issues stay open for years, and the reason why is almost always the corporation didn't want to fix them. Do they invite the community to provide a fix? Nope.
Sure, I can make my own patch for a bug affecting me right now. But then I have to maintain that patch into perpetuity. At that point I'd rather just pay for a commercial proprietary product. So what was the point of the source being open?
RHEL does use Fedora as an upstream but only to rebase major versions. And RHEL may also make different decisions about various components. For example, btfs is now the default file system for Fedora but not RHEL.
CentOS Stream is much closer to RHEL. It's basically the ongoing post-CI builds.
Yep, Fedora is where all new and improved Linux software gets integrated, often being the first Linux distribution where it lands. Many projects (GCC, Gnome any likely others) synchronize their release timelines due to this.
The end result is a a rather nice and lately also quite stable modern Linux distro one can use on a PC and other platforms (there is a IoT edition now, container image, Fedora based CoreOS and others).
Then every ~3 years Red Hat takes a snapshot of a released Fedora version and basically "productizes" it into a new RHEL release.
This means many things, such as cutting package dependencies quite a bit to only ship what the customers expect and what can be expected to be maintainable for the 10 years of support RHEL has. There could be also some "RHELification" when a package is expected to have different default behavior than in Fedora, but most of that is done by spec file macros these days, so RHEL-only RHELification patches are thankfully rare.
Then after a given RHEL version GA, there are minor releases about twice a year. for RHEL 8 for example you have 8.0, 8.1, 8.2, etc.
And this is where CentOS stream actually comes in - it's effectively the continuous RHEL release that makes the point releases possible. Packages are updated for the the next point release and land in CentOS stream, then when all is ready for the next point release of RHEL, it is cut from the properly QAed CentOS stream state, which then starts tracking the next minor release.
This is actually quite an improvement for the usecase of software building on top of RHEL, as instead of getting only a big bunch of surprise twice a year, they can now track what will be in the next release and either adjust or report issues soon enough for them to be fixed before the next point release.
I'm thinking this rather important fact what CentOS stream actually is got kinda "lost in translation" as you can see various things stated as facts about it that are wrong:
"CentOS stream is between Fedora and RHEL" - well, no, it's the source of the next RHEL minor release & nothing goes directly from Fedora to a point release.
"CentOS stream is less stable than RHEL/CentOS" - well, it's the next RHEL, nothing that does not pass the high RHEL standards is expected to land in it for obvious reasons.
What’s your take on the state of “run your own service, beat out the cloud providers”? Is there something particular you’d taken away from Chef “vs” AWS’s OpsWorks?
The article waves this away a little too much for me:
> Could someone take that upstream and create a competitive downstream competitor? Of course. But no one should be able to out-Yugabyte on their home turf.
> Or take Redis Labs. The company has fiddled with licensing over the last few years...
It’s working pretty well for everyone. OpsWorks revenue was smaller than Chef. It grew our pie. Elastic, Redis, Mongo - all far bigger businesses with AWS competitions with them, seeing big growth in their cloud businesses.
Having AWS, Azure, or GCP validate your technology, product, and market is a huge win. Being the prime creator of the product puts you in a very advantageous position (new features, deep support, better user experience). Like the “normal” open source channel, you don’t collect all of the funnel. You do get a new channel (users of rival cloud providers) that operates at a disadvantage compared to your offering (at all but scale, and that’s not an impenetrable one). Those are well qualified users, accustomed to paying for the software. They’re great leads.
Downstream competitors are net good for you. Yes, it means other people get some of the revenue. But some of those would never have used the software in the first place without that competitor, or wouldn’t be used to paying for it. The increase in usage more than makes up for it.
Thanks for the quick response! Let me clarify though.
Each of Elastic, Redis (Labs) and Mongo (and many others) have put licenses in place to explicitly exclude people from taking their code and turn it into a service.
I think that’s fine and their right, as much as making any propriety software (including source available) is someone’s option. But you seem to have a different view about upstream (fully open?) and downstream (scarcity) that I wanted to understand more clearly.
I think it’s inefficient, in a market sense - for the reasons I explained above. All the source available companies we mentioned did that after they got the lift from the open source channel, and the lift from a competitive service. In the case of mongo, the competitor doesn’t use any of their code (making it even more of a straight competitor, meaning it might be harder to extract AWS customers for them).
I think they should’ve stayed/become open source, and instead used their trademark, distribution, and terms of service to ensure a brand monopoly, a-la RHEL.
You can read more about how I came to this conclusion at http://SFOSC.org
I know this is a little bit of a tangent but after all this I have no intention of using a Red Hat derivative again. Debian is fine and perfectly stable.
94 comments
[ 2.3 ms ] story [ 168 ms ] threadCOSS is the emerging Business model, and helps entrepreneur take the best from Open-source and Cloud
I see references everywhere (including this article) that the "co-founder of CentOS started a new distribution: Rocky Linux".
I am not familiar with the history of CentOS, so I tried to understand who Gregory Kurtzer is, and to be honest, I am still not quite sure what he did for CentOS.
My understanding is that he helped start the project and more or less helped it grow during the first 2 years, then was somehow removed from the leading board?
https://blog.centos.org/2019/03/greg-kurtzer-centos-founder/
This story is very unclear to me. It seems McGaugh started CentOS, and then handed it over to "someone in the UK" instead of Gregory Kurtzer.
https://en.m.wikinews.org/wiki/Gregory_Kurtzer_discusses_pla...
The second article make it seem like McGaugh was some kind of employee of Kurtzer:
> One of our developers, Rocky McGaugh, quickly rebuilt the sources in RHEL to give us a stable foundation. That was the beginning of CentOS
I really don't want to start a flame war here, just curious of understanding who this guy is really.
It seems clear from a quick googling that Greg started the project; once Rocky McGough entered the picture, Greg handed him the technical reins while he "continued to manage the project, community, and governance side of things", until he moved on.
(Side note: Distrowatch is one of the unsung pillars of the Linux ecosystem. For all its drawbacks, it has run for almost 20 years, and still works fine as a quick way to survey the field of Linux distributions.)
It's not clear how this would work with a Linux distribution that has already been commoditized by the cloud vendors. Amazon Linux is a CentOS rebrand, and probably soon Amazon Linux will stand on its own feet similar to ElasticSearch, thanks to the Red Hat move
AL2 doesn’t map up to a single version of CentOS already and Amazon would probably be happy to move to being upstream of RHEL for the sake of their kernel team.
Note AWS has a known limited set of hardware. While they do allow install of Amazon Linux outside AWS, that isn’t core to the business or product.
Amazon Linux outside of Amazon is purely to facilitate local build and test pipelines, both of which are meant to encourage AWS deployments. They don’t directly make money off it.
This level of enterprise customer is a tough nut to crack because of the infrastructure monolith that lives inside.
Perhaps they might spend the money for professional services or something in their private cloud, but that money is peanuts compared to the valued created by the free software.
As far as my business experience goes, I would say this is what can make such a system: your sales force. Have a very good sales team that lands a couple of large key clients early.
Yes, it is still the case after +30 years old web and a +10 years old iPhone: the buying decisions include a myriad of reasons, many of them non-technological. A good sales expert can slash through that.
So, yeah, courageous and good management can make it. Specially in a case like this, were it is not necessary to make a paradigm shift in innovation happen. Here we have a player who just needs to box himself onto the table and keep dancing.
Now you have two problems.
The vendor, and the vendor's vendor, who is (cloud provider). There will be resource limits, VPC peering limits (1g, 10G , 100G), and a myriad of other things that subtly change how deals are done and the donuts are made.
Then, when clients are big enough, these vendors quickly begin to offer bespoke solutions which, again, subtly change how they operate and do business.
This creates friction at all levels because we now have classical bespoke enterprise solutions inside "uniformed" scalable cloud solutions.
We might have just as well stayed in place and expanded in our own data center, run it ourselves in the compute cloud, or in some smaller cases, just buy the company we wanted to do business with.
The software biz these days is a dark forest.
It seems hard to believe their success could be attributed to “a hosted cloud service” given that the core product didn’t even support TLS or SSL natively until this past year.
In 2020, you would expect websites not to require a database connection for main views - or at least support a degraded mode (tracking off...).
https://webcache.googleusercontent.com/search?q=cache:9ahQ75...
It's a feature not a bug that we all have different skills. I certainly do not want to discourage others from sharing their opinions due to technical issues that could be resolved more easily by developers (through their implementation and documentation) as much if not more than end users in a given situation.
Well, I mean, you can front the blog with Cloudflare using their wizard for free without any technical knowledge. What kind of DevOps magic do you need there?
I do imagine that this particular issue is causing the author of the post anxiety due to it's unforseen (to them) failure. I'd prefer the computer not discourage them.
As @pepemon points out, the free tier of CloudFlare is probably sufficient and most of the non-tech people running their own variant of WP I know of stopped after being attacked (successfully...) by bots at some point. If you lack tech skills, I think it's best to go to wix, squarespace etc. anyway but platforms are definitely not a requirement and you'd be surprised by the amount of (again non-tech) people who can learn to use a static site generator (with premade theme) and host it using vercel or even S3. At some point, if you want to spread a message, it's worth learning how to do it.
I don't understand why RH don't just allow downloading RH for free like they used to. They tried to funnel non-enterprise types into Fedora - it obviously doesn't work for everyone. There always be an Amazon Linux, Oracle Linux, Scientific or CENTOS, which are not improving RHELs brand.
Personal opinion: They shouldn't have announced anything until those plans were ready, it would save everyone a lot of headaches.
One way of looking at that is to see CentOS as a gateway into the RHEL world, and especially a way for people to get experience with it or test open source software on it. I think that viewpoint just lost out to the other one seeing every CentOS install at a company as lost revenue. That’s not entirely unfounded but I suspect it will produce less revenue and cost them more in network effects than they anticipated. Any open source project, for example, has just been told that they need pay to test Red Hat compatibility.
OSS is an important aspect of being a free citizen in the Information Age.
I think that depends on what you mean by "control" and "really own".
Recently folks were complaining that Apple is acting as a monopoly because you can't install a non-Safari browser. Of course they're still stuck installing from the app store. So, demand installing from outside the app store, and they're still stuck using iOS. Demand changing the OS, and they're still stuck using Broadcom chips and indirectly supporting the CCP.
These are all degrees of control, with associated trade-offs. Being able to easily alter and recompile an application is just one degree of control. There are many others you still won't have until you can fabricate a device from raw materials. And even then maybe your government won't allow you to access the necessary designs and materials (enforced by men with guns).
Ultimately, everything is a package deal, and there is really no such thing as "owning" nor "full control", there are just contracts. For example, no one "really owns" their home; they rent the land from the government and (for most folks) the bank.
> my ability to participate in the Information Age is limited
Indeed, because that system works for its own purposes, not for you. You must conform to it, not vice versa. [1]
[1] https://theanarchistlibrary.org/library/fc-industrial-societ...
Third paragraph of the preamble at https://www.gnu.org/licenses/old-licenses/gpl-1.0.html. Still unchanged in v3: https://www.gnu.org/licenses/gpl-3.0.html
GPL has always been about free-as-in-freedom, not free-as-in-beer.
(No, the GIMP is not good enough to do professional graphic design work. Etc etc pp)
LibreOffice, you probably know that Excel is one of the biggest software platforms out there. So, I can see a chance here, when you sell script/macro development, but I wouldn't know why anyone would want LibreOffice. It's just in use because nothing else is available on Linux.
Blender is probably very good, but people who need such stuff don't necessarily look too much on price. Performance is more important there.
I don't know enough about music production to comment on Ardour.
What I said about Krita is true. I think you don't understand that market and it's priorities and thus gained a wrong impression of the meaning of my words.
https://en.wikipedia.org/wiki/Blue_Ocean_Strategy
Edit: someone mentioned AWS Linux and k8s below, I think it's really off in business terms. Those things are open and free in order to "commoditize the complement" https://www.gwern.net/Complement
Because their legal department prohibits them from running AGPL code :). That's a side reason for non-standard open source licenses I suspect. The hassle of getting legal to approve them is more than the cost of just paying for a commercial license.
Source : https://redislabs.com/redis-source-available-license
At least 90% of the products value is tied to the Linux kernel itself. The majority of which comes from development effort outside Red Hat. (How many customers would stay if IBM hypothetically kept the userland and swapped to an AIX kernel?)
there's a reason people use linux distros over building their own
The low-level integration is just as good in Debian/Ubuntu land too. Hell, Arch does it too pretty well. (There's an announcement list about manual updates, it's worth subscribing to even if you don't use arch[0], because usually the same change will percolate down on the grapevine and next releases of other distros will also change similarly.)
[0] btw, I don't use arch
They also have in-house expertise for most critical Linux subsystems, which could in theory be useful if you are a paying customer.
But at the same time there are many other ways to get really competent support. Of course not for their frankenkernel. But again, were I operating something critical I would likely want to budget for regular updates that support newer HW/firmware/kernel/libc ... but we all know that certifying all that is much more expensive than just occasionally running yum upgrade. ¯\_(ツ)_/¯
As of the most recent analysis that I've been able to find [0] (2018), Red Hat was the #1 most active corporate contributor to the kernel (drivers excluded - Intel and AMD do a lot of support for their own hardware), IBM was #2, and Amazon isn't even on the list.
And while I can't find any statistics on contribution breakdowns for GCC, glibc, Xorg, Mesa, Grub2, and other important pieces of the ecosystem, Red Hat does a lot of maintenance and development work outside of the kernel as well.
* Pipewire (Wim Taymans)
* RADV Mesa Vulkan Driver (David Arlie)
* Firefox Wayland support + hardware acceleration support + GCC compilation validation (Martin Stránský)
* The plurality of GCC and Glibc and (until recently) Xorg maintainers
And so it goes with a lot of other components.
[0] https://lwn.net/Articles/775440/
(I actually found more recent ones after posting this, they look mostly similar although IBM dropped further down the list)
No other publicly traded company I know of ever had a track record like that. I hope that philosophy stays/grows within IBM.
If the software you are trying to sell, is GPL, then anyone can do the same as CentOS at any time.
The article suggests users will arrange into two groups, non-paying users of the develelopment version and paying customers of the production-class version.
But the production version is still GPL and so anyone can get the production version for free any time they want.
Your only option for getting out of that is not to use any GPL software in your super valuable commercial product.
That is the GPL deal, which you don't have take. You can take it OR leave it.
What RedHat seems to have forgotten was 2 things, which I'm sure they knew very well at some point:
- Even non-paying users are more valuable to you as non-paying members of your ecosystem than members of any of your competitors. They are actually what keeps your ecosystem a defacto standard. It is incalculable how valuable it is to be a defacto standard for anything.
- Those non-paying users were never and are never going to be paying customers no matter what else you do. Their use is not "lost revenue" because you were never going to get any revenue from them anyway. If they couldn't use your product for free, they'd just use someone else's product for free. There is no "convert them into paying customers".
And there is also no "convert them into development version users" either because of see above re GPL.
All it is is annoying for everyone, even bystanders, that they keep trying.
That's not correct. Anyone who is already a user can. If you restrict distribution of the binaries, you also restrict the amount of people who can get the sources. You cannot impose NDAs or the likes, but you can introduce some restrictions on their overall privileges going forward (i.e. you republish sources? No more patches or support for you - which is basically what RH does with their paying customers).
RH could stop publishing sources entirely, if they really wanted to, and just provide them to paying customers on request. They don't do that because it's a nuclear option that would effectively push them out of the Linux ecosystem they've invested so much into dominating (RH is effectively the one company who can steer massive amounts of the Linux ecosystem on its own - as shown by systemd et al).
This is only true if paying customers aren't constantly transitioning to become non-paying members, because CentOS is "official" and "just as good as RHEL" in every respect including the length of support.
The title should read though, "Cofounder of Chef on Centos being open source."
Chef, like Puppet, is used to manage server configurations.
Honestly, screw everyone that uses some annoying "Open Source unless you compete with me" license, or doesn't include non-corporate engineers on an oversight board for the project. I don't give a crap if your code is available if you never accept the PRs that I make, or never address the issues I raise. Often these issues stay open for years, and the reason why is almost always the corporation didn't want to fix them. Do they invite the community to provide a fix? Nope.
Sure, I can make my own patch for a bug affecting me right now. But then I have to maintain that patch into perpetuity. At that point I'd rather just pay for a commercial proprietary product. So what was the point of the source being open?
CentOS Stream is much closer to RHEL. It's basically the ongoing post-CI builds.
The end result is a a rather nice and lately also quite stable modern Linux distro one can use on a PC and other platforms (there is a IoT edition now, container image, Fedora based CoreOS and others).
Then every ~3 years Red Hat takes a snapshot of a released Fedora version and basically "productizes" it into a new RHEL release.
This means many things, such as cutting package dependencies quite a bit to only ship what the customers expect and what can be expected to be maintainable for the 10 years of support RHEL has. There could be also some "RHELification" when a package is expected to have different default behavior than in Fedora, but most of that is done by spec file macros these days, so RHEL-only RHELification patches are thankfully rare.
Then after a given RHEL version GA, there are minor releases about twice a year. for RHEL 8 for example you have 8.0, 8.1, 8.2, etc.
And this is where CentOS stream actually comes in - it's effectively the continuous RHEL release that makes the point releases possible. Packages are updated for the the next point release and land in CentOS stream, then when all is ready for the next point release of RHEL, it is cut from the properly QAed CentOS stream state, which then starts tracking the next minor release.
This is actually quite an improvement for the usecase of software building on top of RHEL, as instead of getting only a big bunch of surprise twice a year, they can now track what will be in the next release and either adjust or report issues soon enough for them to be fixed before the next point release.
I'm thinking this rather important fact what CentOS stream actually is got kinda "lost in translation" as you can see various things stated as facts about it that are wrong:
"CentOS stream is between Fedora and RHEL" - well, no, it's the source of the next RHEL minor release & nothing goes directly from Fedora to a point release.
"CentOS stream is less stable than RHEL/CentOS" - well, it's the next RHEL, nothing that does not pass the high RHEL standards is expected to land in it for obvious reasons.
What’s your take on the state of “run your own service, beat out the cloud providers”? Is there something particular you’d taken away from Chef “vs” AWS’s OpsWorks?
The article waves this away a little too much for me:
> Could someone take that upstream and create a competitive downstream competitor? Of course. But no one should be able to out-Yugabyte on their home turf.
> Or take Redis Labs. The company has fiddled with licensing over the last few years...
Having AWS, Azure, or GCP validate your technology, product, and market is a huge win. Being the prime creator of the product puts you in a very advantageous position (new features, deep support, better user experience). Like the “normal” open source channel, you don’t collect all of the funnel. You do get a new channel (users of rival cloud providers) that operates at a disadvantage compared to your offering (at all but scale, and that’s not an impenetrable one). Those are well qualified users, accustomed to paying for the software. They’re great leads.
Downstream competitors are net good for you. Yes, it means other people get some of the revenue. But some of those would never have used the software in the first place without that competitor, or wouldn’t be used to paying for it. The increase in usage more than makes up for it.
Each of Elastic, Redis (Labs) and Mongo (and many others) have put licenses in place to explicitly exclude people from taking their code and turn it into a service.
I think that’s fine and their right, as much as making any propriety software (including source available) is someone’s option. But you seem to have a different view about upstream (fully open?) and downstream (scarcity) that I wanted to understand more clearly.
I think they should’ve stayed/become open source, and instead used their trademark, distribution, and terms of service to ensure a brand monopoly, a-la RHEL.
You can read more about how I came to this conclusion at http://SFOSC.org
It’s absolutely their right to do. :)
And yes, I think you're on to something. "True" open source is about building communities rather than a strategy to sell proprietary software.