How the Cloud Potentially Rains on the Open Source Software Parade

0

Open source code has helped us through many technological changes and remains the backbone of a surprising amount of modern connectivity. However, the growing shift to the cloud could potentially point us in a different, trickier direction.

In the minds of many, open source code is written by enthusiastic teams of highly trained altruists, giving up their free time in the hope of bringing quality software to the masses. In reality, much of the most important work is done by nine-to-fives in large office buildings, taking the shilling from companies that rely on the open source software they help develop. Sometimes a particularly skilled and enterprising person can turn the situation into a consulting business, although the result is the same: good code is expensive.

Whether or not that explains why the overwhelming majority of open source code is often like this, uh, cheap, the fact remains that some of the most important software in the world – web servers, etc. – remain heavily dependent on the willingness of large companies to release modifications to open source hardware. Tie-wearing senior management might like to portray it as voluntary company largesse, but it’s not a big leap to assume that companies that give time to open source code only deliver the results because that when they distribute the software, they must .

Due to a subtle technical and legal distinction, however, there are fears that the status quo is under threat, at least in some specific areas.

Consider a… cell phone

Consider an Android cell phone, the poster child of the open source zealot, as an example of Linux used by a large number of non-IT people. It doesn’t matter that it’s a false equivalence in the first place. Insisting that Android is “Linux” in the same sense that Ubuntu is “Linux” is, while technically correct, a bit like comparing a lawnmower to a snowblower, as they will burn the same fuel. Forget that, though. What matters is that while Android often finds itself on a pedestal as an open source success story, most of what makes it work isn’t open source.

Yes, it is possible – not very fun, but possible – to run an Android phone based entirely on open source software. The software that makes it After fun, including the overwhelming majority of third-party apps, is proprietary, but that’s not really the point. The problem is that a lot of the software that powers Android phones isn’t even on the phone. It’s on a server somewhere. See how a modern cell phone stops working when not connected to a network.

Where Google got the code that runs Google Maps and what changes Google made to that code is moot if the company doesn’t distribute the resulting software. Apple users don’t need to be smug here; the server farms that run the App Store aren’t rows of gleaming iMacs. They consist of racks full of generic computer hardware running large amounts of open source software, just like everyone else. Did Apple or Google make any proprietary changes to what they use? Probably, but there’s no way to know.

How well the open source paradigm has really worked in practice is a longer story than we have time to tell. Most open source code, by line count, is horrible. A lot of the bad stuff is trivial, the kind of stuff that can be written by a single user in a reasonable amount of time. Much of what isn’t horrible or trivial (and much of what is) are applications directly related to software engineering, code for coders, which will be widely used to create more the same thing. Even if we exclude all of these things, we discover a world of user-oriented software that often offers a user experience about as comfortable as the business end of an orbital sander.

Floating and away

Worse still, as apps drift into the clouds like so many helium balloons, they float entirely out of open source’s reach. In this case, our ability to assess and fix source code is just as limited as under a closed-source proprietary model. The problem is that when code is running on someone else’s CPU, we may not even know the difference, and companies may face a much narrower imperative to donate large sums of money. money in software engineering.

The relationship between lightness thin clients and the servers that keep them filled with data have oscillated at least twice in the history of widespread electronic computing. As soon as computers began to support multiple users at once, the idea of ​​a central computer controlling many terminals became common. Fast desktop computers have changed that. Phones have changed him again. Now we call the terminals “cell phones”, the distances are longer and the signals are wireless, but we still use simple terminals compared to the huge server farms behind them. Whether that will ever change again remains to be seen, but it all looks like a pendulum that may continue to swing.

So there’s an irony here, in that even though the cloud overwhelmingly works on open source code, it might actually not be particularly good at open source code. When Richard Stallman more or less founded the open source movement in the 1970s, he didn’t face many of the problems he faces today. The problems of managing very large projects (there are still no competent open source NLE) were irrelevant on computers unable to run more code than can be comfortably written by one person. The problems of creating applications for non-specialists were irrelevant when computers could only be used by specialists. And, despite living in a world where mainframe-terminal arrangements were common and the internet precursor ARPANET was well known, Stallman hadn’t anticipated the cloud.

And if more code moves to the cloud, it’s at least possible that companies will become less willing to make the very large, very valuable, publicly available contributions that they often have to this day. What we do next is currently anyone’s guess.

Share.

Comments are closed.