Slashdot Mirror
Is Open Source Innovation Now All About Vendor On-Ramps? (infoworld.com)
InfoWorld published an interesting essay from Matt Asay, former COO at Canonical (and an emeritus board member of the Open Source Initiative), about innovation from the big public cloud vendors, which "even when open-sourced, doesn't really help the community at large... All this innovation is available to buy; none of it is available to build. Not for mere mortals, anyway."
Google in particular has figured out how to both open-source code in a useful way and make it pay. As Server Density CEO David Mytton has underlined, Google hopes to "standardize machine learning on a single framework and API," namely TensorFlow, then supplement it "with a service that can [manage] it all for you more efficiently and with less operational overhead," namely Google Cloud. By open-sourcing TensorFlow and backing it with machine-learning-heavy Google Cloud, Google has open-sourced a great on-ramp to future revenue.
My question: why not do this with the rest of its code? The simple answer is "Because it's a lot of work." That is, Google could open-source everything tomorrow without any damage to its revenue, but the code itself would provide other providers and enterprises only limited ability to increase their revenue unless Google did all the necessary prep work to make it useful to mere mortals not running superhuman Google infrastructure. This is the trick that AWS, Microsoft, and Google are all racing to figure out today. Not open source, per se, because that's the easy table stakes. No, the AWS/Microsoft Azure/Google Cloud trio are figuring out how to turn their innovations into open source on-ramps to their proprietary services. Companies used to lock up their code to sell it. Today, it's the opposite: They need to open it up to make their ability to operate the code at scale more valuable. For them.
My question: why not do this with the rest of its code? The simple answer is "Because it's a lot of work." That is, Google could open-source everything tomorrow without any damage to its revenue, but the code itself would provide other providers and enterprises only limited ability to increase their revenue unless Google did all the necessary prep work to make it useful to mere mortals not running superhuman Google infrastructure. This is the trick that AWS, Microsoft, and Google are all racing to figure out today. Not open source, per se, because that's the easy table stakes. No, the AWS/Microsoft Azure/Google Cloud trio are figuring out how to turn their innovations into open source on-ramps to their proprietary services. Companies used to lock up their code to sell it. Today, it's the opposite: They need to open it up to make their ability to operate the code at scale more valuable. For them.
The author offers the fact that Google open sources some of its software to profit off of the support it provides in a tone that suggests this is a problem. This is one of those everybody wins scenarios which Richard Stallman dreamed about when he invented the GPL. Can anyone explain to me what reason the author has to be upset other than "someone other than me is making money"?
Open Source software has always been used in myriad ways, and continues to be.
So the real question is "is there a profound shift in balance that we need to discuss".
I don't know.
What I do know is that the phrasing "now all about" is vague and tendentious. Perhaps someone can point to some recent research on the subject?
As an old saying goes, there's no such thing as a free lunch. If a business is giving you something, it's as a hook to make money. Not that it's necessarily a bad thing but it's pretty obvious why AMD makes drivers primarily for AMD cards. Sometimes it's just auxiliary like they're giving you developer tools to build applications for their platform. Whether it's open source or closed source doesn't really change that. Is this a bad thing? Well, you should be aware that like everyone they have their motivations and their incentives may be contrary to yours.
Like most recently I was looking at an open source client-server solution, where their server is a central cloud service. The client had like really easy paint-by-numbers steps to build and run. The server had almost zero information, a dummy config file with no comments and gives nearly zero useful feedback. It doesn't even build out of the box due to checks and tests that depend on missing settings and keys. The curt replies from the company are basically "we don't have time to support other people trying to run the server". That might be true, but they don't have any incentive to make it easy either.
But I suppose that's mostly fair, it's no different than when individual open source developers don't want the changes I'd like to make. What is unfair is that they might come up with all sorts of excuses to avoid accepting your contribution, without disclosing their true reason for rejecting it. There's a lot of power in simply stonewalling you and saying we don't care if you want that even if you got a patch ready to go, make your own fork. Then again there's many people with bad ideas and bad code, refusing to accept it might totally be the right choice. The question is just whether you're doing it in good faith or not.
Live today, because you never know what tomorrow brings
The simple answer is "Because it's a lot of work."
No, it's because this is by design. They open source enough to improve image and maybe help get started, but keep closed anything that they think is fundamental to their strategy. This is not just google. Among the known cloud vendors, not *one* open sources any of their backend software. They all have something home grown. They have plenty of open source libraries to act as a client to their back end software, but software that is useless for interoperabilty between vendors or building your competing system. They also enjoy posting articles that *claim* to tell you how they do things, but proceed to omit any actionable details and lay on the buzzwords thick instead. Those articles are crafted to make it sound *really* hard and that they are so clever, but without actually reveling their hand or helping anyone in the slightest. They seem designed to make people feel intimated at the prospect of managing their own infrastructure by making the task seem far more exotic and arcane than it is.
It's not just cloud vendors. There are many electronic devices with open source libraries, but they only work with the respective closed firmware implementations.
I'd say broadly a transformation in standards and open source has happened in the last 15 years or so. In the late 90s you had this overwhelming emergence of standardization and openness in the industry. AOL, CompuServe, Prodigy et al gave way to the federated internet, IETF had a great body of standards and looking at the authors of the standards, they almost always including 'customers' alongside vendors. Linux began overwhelming the Unix market, and this inspired a lot of exploration of open source software. Over the past 15 years, people are locking away a lot of their infrastructure in distinct proprietary cloud providers. The web is more and more about helping people access the social network of the day, none of which are the least bit federated (discarding net neutrality will further reinforce this). You look at 'standards' and the authors are pretty much *always* on the vendor side now, and strangely these 'standards' don't facilitate interoperabilty, but give the vendors a way to claim they are using an industry standard without actually doing anything that would help in the way a standard should.
In short, standards, open source, and the internet all blindsided the vendors when it first took hold of the industry. Over time, the vendors have mastered the art of manipulating those things to their benefit, to let people *feel* like they are continuing the great open revolution, all while the gardens are being walled and the customers are getting locked into their vendors by using the newest 'standard' to interact with product.
XML is like violence. If it doesn't solve the problem, use more.
Well, there is at least a kernel of something in that first sentence... Small teams can be often far more effective than a large team. Trying to overcome limitations through quantity of developers won't win the day.
Take an arbitrary well established and known project with 'thousands' of contributors. They will almost all have about six to twelve people carrying the project, and a thousand trivial commits for little things, mainly for resume boosting.
XML is like violence. If it doesn't solve the problem, use more.
The problem with PulseAudio was that the distros included it early, to do the debugging in the wild, and so people using it the first few years suffered a lot. And now that it has been solid and stable for a long, long time, the neckbeards remember having a bug they didn't know how to fix, and feeling frustrated and stupid because they couldn't make their computer work, and so they'll never forgive Frodo for stealing the Precious!
It is sad, really. They were born simple and thrown into a very complex world, they don't know any different.
For me it was always obvious that the old sound system was monolithic and designed around a single lowest-common-denominator instead of following UNIX principles of being a generic interface. Sure, I spent years disabling PulseAudio as the first step after OS installation. And then when the bugs got fixed, I started using the new features. It is so nice to be able to start a video on my main screen, and then just switch a TV input to "HDMI" and send the (still running) video to that screen, and then open the mixer and switch the audio seemlessly to the HDMI output. In the old days you had to switch the audio in advance; if it was a live stream or something, your only hope was to use an external audio receiver!
Wayland appears to just be written by people who want to make a name for themselves, and didn't have anything better than paradigm thrash to do it. X Window System forever!