Does the Open Source Movement Need to Evolve? (techcrunch.com) 72
A cloud company's CTO argues on CTO that the "hypocrite commits" controversy "is symptomatic, on every side, of related trends that threaten the entire extended open-source ecosystem and its users."
That ecosystem has long wrestled with problems of scale, complexity and free and open-source software's (FOSS) increasingly critical importance to every kind of human undertaking. Let's look at that complex of problems:
- The biggest open-source projects now present big targets.
- Their complexity and pace have grown beyond the scale where traditional "commons" approaches or even more evolved governance models can cope.
- They are evolving to commodify each other. For example, it's becoming increasingly hard to state, categorically, whether "Linux" or "Kubernetes" should be treated as the "operating system" for distributed applications. For-profit organizations have taken note of this and have begun reorganizing around "full-stack" portfolios and narratives.
- In so doing, some for-profit organizations have begun distorting traditional patterns of FOSS participation. Many experiments are underway. Meanwhile, funding, headcount commitments to FOSS and other metrics seem in decline.
- OSS projects and ecosystems are adapting in diverse ways, sometimes making it difficult for for-profit organizations to feel at home or see benefit from participation.
Meanwhile, the threat landscape keeps evolving:
- Attackers are bigger, smarter, faster and more patient, leading to long games, supply-chain subversion and so on.
- Attacks are more financially, economically and politically profitable than ever.
- Users are more vulnerable, exposed to more vectors than ever before.
- The increasing use of public clouds creates new layers of technical and organizational monocultures that may enable and justify attacks.
- Complex commercial off-the-shelf solutions assembled partly or wholly from open-source software create elaborate attack surfaces whose components (and interactions) are accessible and well understood by bad actors.
- Software componentization enables new kinds of supply-chain attacks. Meanwhile, all this is happening as organizations seek to shed nonstrategic expertise, shift capital expenditures to operating expenses and evolve to depend on cloud vendors and other entities to do the hard work of security. The net result is that projects of the scale and utter criticality of the Linux kernel aren't prepared to contend with game-changing, hyperscale threat models.
Among other things, the article ultimately calls for a reevaluation of project governance/organization and funding "with an eye toward mitigating complete reliance on the human factor, as well as incentivizing for-profit companies to contribute their expertise and other resources." (With whatever culture changes this may require.) It also suggests "simplifying the stack" (and verifying its components), while pushing "appropriate" responsibility for security up to the application layer.
Slashdot reader joshuark argues this would be not so much the end of Open Source as "more turning the page to the next chapter in open-source: the issues of contributing, reviewing, and integrating into an open-source code base."
- The biggest open-source projects now present big targets.
- Their complexity and pace have grown beyond the scale where traditional "commons" approaches or even more evolved governance models can cope.
- They are evolving to commodify each other. For example, it's becoming increasingly hard to state, categorically, whether "Linux" or "Kubernetes" should be treated as the "operating system" for distributed applications. For-profit organizations have taken note of this and have begun reorganizing around "full-stack" portfolios and narratives.
- In so doing, some for-profit organizations have begun distorting traditional patterns of FOSS participation. Many experiments are underway. Meanwhile, funding, headcount commitments to FOSS and other metrics seem in decline.
- OSS projects and ecosystems are adapting in diverse ways, sometimes making it difficult for for-profit organizations to feel at home or see benefit from participation.
Meanwhile, the threat landscape keeps evolving:
- Attackers are bigger, smarter, faster and more patient, leading to long games, supply-chain subversion and so on.
- Attacks are more financially, economically and politically profitable than ever.
- Users are more vulnerable, exposed to more vectors than ever before.
- The increasing use of public clouds creates new layers of technical and organizational monocultures that may enable and justify attacks.
- Complex commercial off-the-shelf solutions assembled partly or wholly from open-source software create elaborate attack surfaces whose components (and interactions) are accessible and well understood by bad actors.
- Software componentization enables new kinds of supply-chain attacks. Meanwhile, all this is happening as organizations seek to shed nonstrategic expertise, shift capital expenditures to operating expenses and evolve to depend on cloud vendors and other entities to do the hard work of security. The net result is that projects of the scale and utter criticality of the Linux kernel aren't prepared to contend with game-changing, hyperscale threat models.
Among other things, the article ultimately calls for a reevaluation of project governance/organization and funding "with an eye toward mitigating complete reliance on the human factor, as well as incentivizing for-profit companies to contribute their expertise and other resources." (With whatever culture changes this may require.) It also suggests "simplifying the stack" (and verifying its components), while pushing "appropriate" responsibility for security up to the application layer.
Slashdot reader joshuark argues this would be not so much the end of Open Source as "more turning the page to the next chapter in open-source: the issues of contributing, reviewing, and integrating into an open-source code base."
All those words say much less than they seem to (Score:5, Informative)
Glancing through the article, despite the broad hand-waving nature of the listed points... it really seems he's mostly worried about the Linux kernel in particular. And it also seems he's extrapolating from one data point - the Golden Gopher problem commits.
These "new, bigger" threats are a problem for everyone - not just FOSS. And I'd argue the kernel maintainers are as well equipped as anyone to deal with these threats - the Linux kernel is big business. It's not maintained by a bunch of volunteers. This isn't the 1990s anymore.
Re: All those words say much less than they seem t (Score:2)
Re: All those words say much less than they seem t (Score:5, Insightful)
part of me is glad that _someone_ is thinking about this stuff.
Perhaps. But if that someone is from a freeloading cloud company that uses OSS, but contributes little or nothing back, it doesn't mean much.
Advice is more helpful when it comes from someone willing to pitch in and contribute.
Re: (Score:2)
Well like he said it's an "everybody" problem. Doesn't matter who's saying it. Matters who's doing anything about it.
Three stages of solving a problem (Score:2)
There's something I've noticed over a couple decades watching the development of internet technologies and standards. Both looking at the academic research level and the practical application in working software and IETF standards such as HTTP, SMTP, etc.
There are very often three stages to coming up with really good solutions to hard problems:
In the first stage, someone clearly identifies/defines the problem, and shows why it's important to solve. Perhaps they give some broad overview of classes of potenti
Re: (Score:2)
I think it's better to visualize the solution first, then compare that situation with the existing situation. If there is no solution, then the existing situation just has to be endured. If some plausible solution exists, then you have to consider how to get there from here.
As regards OSS, the solution approach I've been advocating for many years would involve cost recovery with the basic principle being anything can be supported as long as someone is willing to pay the costs up front. My favorite (imaginar
Re: (Score:2)
> I have pretty much stopped using OSS. In the absence of a viable and stable financial model, I regard it as too unreliable.
The big number one producer of proprietary software has been switching to use open source instead, because they regard the proprietary model as unreliable. For example, they are shifting Azure to run on Linux, with no need of Windows.
It's kinda like you're betting on the candidate who dropped out of the race and endorsed their rival.
Re: (Score:2)
I think it's different. They are buying up the OSS movement because it's cheap. I'm not saying there's no value there, but rather that I have no influence on it. In contrast, the makers of proprietary software have plenty of money from their fundamentally evil financial models to allow them to buy the good ideas, and the greed to buy them cheap. Future features of the software will be the ones they like and "troublesome" features will start disappearing.
In a sense, it's a guaranteed loss for my side. I thin
Re: (Score:2)
How can you visualize a solution when you have no clear idea of the problem?
Like your decision to stop using OSS. What exactly is the problem you are afraid of? "Absence of a viable and stable financial model" is not a problem for software which is not based on finances. You're making your decision based on criteria which you have taken unaltered from how a company is run and applied that to how open source projects work.
That is a category error. Your decision makes no sense, because you have not modeled th
Re: (Score:2)
I can't tell if my writing was unclear or if your reply is some kind of troll. Or perhaps OSS fanaticism? (Which is most often based on confusion around the words "free" and "freedom".) But I'll make an attempt to clarify.
Perhaps "solution" is the wrong word to start with, but "state of affairs" is rather cumbersome. Ditto "different way of doing something" or similar phrases. By "solution" in this context I mean a condition that is different (and hopefully measurably better) compared to the way things are
Re: (Score:2)
Nice analysis. I will use it as a framework from now on.
Re: (Score:2)
Thanks, Phantom Five.
Re: (Score:2)
Perhaps. But if that someone is from a freeloading cloud company that uses OSS, but contributes little or nothing back, it doesn't mean much.
This is a legitimate use of OSS. If you create an OSS project, and you don't want cloud companies freeloading, you can make your license terms exclude this kind if use!
I find this attitude hypocritical. "We want free open-source software, but we don't want you to use it to make money." OSS projects have found out that if they exclude commercial use, their projects don't usually get as much traction as they would with commercial use.
Re: (Score:2, Informative)
It's not maintained by a bunch of volunteers.
Yes it is. Other than Linus Torvalds and Greg KH, I don't know of any other maintainer that is employed by the Linux Foundation. Other maintainers may have convinced their employers to fund them, but that is not an official guarantee and so they may as well be considered volunteers still.
Re:All those words say much less than they seem to (Score:5, Insightful)
Wow, that is a rather bizarre definition of “volunteer” you’ve chosen to stand behind. I’m sure the guys from Google, Facebook, VMware, Red Hat / IBM etc. who are paid to work on the Linux kernel (and have many, many, many accepted commits this year and in past years) appreciate not being considered professional.
Re: (Score:1)
When the heck did "volunteer" become a pejorative?
120 years ago, "professional" was essentially a slur tossed around at yacht clubs.
I despise deeply what commerce has done to our hobby.
Re: (Score:2, Informative)
not being considered professional.
The counterpart to "professional" is "amateur", not "volunteer", you ignoramus.
And "professional" literally just means paid. Some amateurs have even performed better than professionals.
Maybe you should learn English properly.
Re: (Score:1)
...you ignoramus.
Haha. The Bazaar in a nutshell.
(Maybe you're just too young.)
Re: (Score:2)
I would think a large consortium of Universities would be the best group to host, promote and contribute to core FOSS programs.
You are using the students and lecturers to contribute code, detailing code, writing instruction manuals, creating learning tools. Those students and lecturers earning public recognition for future career opportunities. Pay for research positions, sell development of coding elements. Universities teaching the real pointy edge of FOSS program development, more advanced universities
Re: (Score:1)
Re: (Score:2)
And the focus was on "Open Source" rather than "Free Software", so I suspect his ... interests ... may not be the same as mine.
That said, yes, the community needs to evolve. One obvious way is to be less reliant on large projects. Many projects are needlessly large, when what is needed is agreement on standards of communication. Smaller projects are easier to validate. E.g., most gui software doesn't need to be integrated into the window manager.
OTOH, each project requires its own management team, mecha
Re: (Score:1)
Re: (Score:1)
If someone wanted to have the debate about the relative risks between open source vs closed source at discovery of potential exploits... sure!
I reject that "corporate" code is really any more (or less for that matter) secure than anything else simply by virtue that "it's not FOSS." That's nonsense.
Pile of Excrement (Score:5, Insightful)
What a huge heaping pile of excrement!
"The biggest open-source projects now present big targets."
So what? The biggest closed-source projects now present big targets, too.
"Their complexity and pace have grown beyond the scale where traditional "commons" approaches or even more evolved governance models can cope."
Facts not in evidence. This is speculation.
"They are evolving to commodify each other. For example, it's becoming increasingly hard to state, categorically, whether "Linux" or "Kubernetes" should be treated as the "operating system" for distributed applications."
No, this is total bullshit. Linux is an Operating System. Kubernetes is not. No matter how much pot you smoke or acid you drop, this fact will not change.
"Attackers are bigger, smarter, faster and more patient, leading to long games, supply-chain subversion and so on."
And what does this have to do with anything at all?
"Attacks are more financially, economically and politically profitable than ever."
And what does this have to do with anything at all?
"Users are more vulnerable, exposed to more vectors than ever before."
Only if those "users" are running open or closed source software that is designed by the addle (which is most of it).
"The increasing use of public clouds creates new layers of technical and organizational monocultures that may enable and justify attacks."
This is true. Anyone who puts anything of importance on "other people's servers over which they have no control" deserves whatever they reap.
"Complex commercial off-the-shelf solutions assembled partly or wholly from open-source software create elaborate attack surfaces whose components (and interactions) are accessible and well understood by bad actors."
What does this have to do with anything at all?
"Software componentization enables new kinds of supply-chain attacks. Meanwhile, all this is happening as organizations seek to shed nonstrategic expertise, shift capital expenditures to operating expenses and evolve to depend on cloud vendors and other entities to do the hard work of security. The net result is that projects of the scale and utter criticality of the Linux kernel aren't prepared to contend with game-changing, hyperscale threat models."
It is true that the one tends to get what one seeks.
Since you asked (Score:3)
You asked several times "what does this have to do with anything"?
The point of the article is that attackers are now more sophisticated, better funded, and more motivated - while software systems have grown more complex and harder to keep safe. Therefore, the author says, the development process needs to adapt to the changing complexity and risks.
With the point of the article in mind, maybe if you re-read your own post you can answer your own question of "what does this have to do with it"?
As to your first
Re: (Score:2)
The Internet has basically become a hostile place and we need an operating system which remains secure even when the software running on it isn't.
I'm hoping the U.S. government at some point will mandate the use of micro-kernel operating systems since we cannot wait for all software to be rewritten in Rust or some other safe language.
Thirty four years (Score:2, Interesting)
Minimizing the size of the TCB is under important for security.
Tanenbaum and all of the other microkernel enthusiasts have had 34 years since his initial release to come up with something that actually works. Something that is actually usable.
Tanenbaum's Minix was around years before Linux. Linus would have used it instead of having to develop his own OS, of the microkernel approach was usable. He didn't use as nobody used it - because it does not work.
We have found what does work better to minimize the siz
Re: (Score:2)
And I'm pretty sure both Windows and Linux could be rewritten to a micro-kernel architecture without too much effort. But in order for that to happen users will have to mandate it, and the only one powerful enough to do that is the U.S. government.
Hypervisors offer no protection at all from malware and such, as we'll see in the not so far future.
Re: (Score:2)
Yep, lots of people have written micro-kernels, and nobody uses them - not even the people who wrote them. Ghost is aptly named, though.
> Linux could be rewritten to a micro-kernel architecture without too much effort. But in order for that to happen users will have to mandate it, and the only one powerful enough to do that is the U.S. government.
You do know Linux is a kernel, right?
If it was a microkernel, it wouldn't be Linux anymore. It would be yet another Microkernel that nobody uses, because that's
Re: (Score:2)
Re: (Score:2)
Yes it is. I don't think you quite understand how a microkernel was supposed to help, and how technology has advanced over the last 35 years to provide far greater protection than a microkernel could offer. With much higher performance.
The idea of a microkernel was that the kernel, the TCB, would run as several different processes. That way, an exploit of your mail server would only affect the programs that use the same part of the kernel that your mail server uses. It wouldn't effect, say your Active Direc
Re: (Score:2)
Torvalds needs to get his act together and concede to Tanenbaum that micro-kernel operating systems are MUCH more secure than monolithic beasts like Linux.
Security isn't the top priority for Linux. Whether that is the right decision or the wrong decision, it is the decision they have made.
Re: (Score:1)
Torvalds needs to get his act together
No, he doesn't.
Re: (Score:3)
The OP was right that the essay makes a lot of dodgy assertions and assumptions. Just about the only one that holds up is the fact that open source projects have gotten so widely used that it's worthwhile for attackers to try supply-chain attacks with them. (Contra OP, this is different from closed source/proprietary software because the latter does not typically accept code changes from third parties.)
Take, for example, the claim that users are exposed to now attack vectors than before. That's maybe tru
Re: (Score:3)
"Open source" isn't a company... (Score:3, Insightful)
Re: (Score:3)
Company? No. Want to be part of the larger picture? Yes. That means change. And to a degree it can be managed because a lot of the developers are employees of various companies.
THe problem with open source is (Score:4, Interesting)
These are the exact type of person where they are all about profits and mega bonuses for themselves and forget about th elittle people who actually do the work.
DO us all a favour and fuck off with you and your type.
Re: (Score:1)
Stop side stepping the issue. The real problem here like so much of america is corporate america and their greed.
>> DO us all
> You don't speak for me. Capiche?
Strange that you would defend CEOs rather than admit they cause considerable harm with their never ending greed.
Speciation (Score:4, Insightful)
Re: (Score:1)
Forks happen, but not as many as one might expect. That might be because it is a lot of work to keep a project going, especially a major one.
For instance, I know of one popular Open Source office suite (Libre Office) and was forked after years of not much going on in Open Office. Eventually, the community lost patience and part of the contributors left. But it took quite some time before it happened.
Re: (Score:2)
Re: (Score:1)
Or fork the whole thing, as is the case with BSD-like licence projects. No collaboration, just endless forks and new projects.
Oh, "new projects" = bad. Endless? That's a lot. But it's certainly fewer than the number of Linux distros out there, all with the same old kernel and Linus' stamp of approval. Sort of like American cars in the 1950s, "Well boss, we just copied the Bellaire but then, WE MADE THE FINS HIGHER!" "Great work Lewis, I like it!"
It's this sort of my-way-or-the-flyway arrogance that caused me to leave Linux for a BSD. And I saw just how good they are.
Sounds like a lot of whining to me. (Score:4, Interesting)
OSS projects probably don't much care about your feelings.
I'm sorry,... whose fault is it that your company has decided to let all of the technical people go? To move all your infrastructure out to an external entity? Seems to me that the threats you're worried about are occurring because your company decided to go cheap on its internal expertise and bet the farm on Amazon, Google, et al. As a result, your real beef is with them---not with OSS. If you're uncomfortable with componentization, perhaps you should contact a company like CA. They may still have their enterprise architecture that you can become locked into^W^W^W invest in.
Citation, please. Your CTO title means nothing.
The solution is as obvious as it is hard... (Score:5, Interesting)
... reduce complexity. There is a reason why most Free Software operating systems are unixoid. It simply is a design where you can get the most "bang for the buck". It's a system of few orthogonal features you can use to solve surprisingly complex problems with very little effort.
Now contrast that with the current state of the web. While it did start out as something "free", we now have its standards controlled by a few huge companies. Those companies all have no interest in a web that is easy to implement. Every bit of complexity makes it harder for their competitors to keep up with it. Therefore they all have an interest in making such standards as complex as possible.
The result that the Web today is very unfree, but not because of licenses, but because of complexity. I believe the web is a lost cause. It's document centered design makes it hard to do interactive applications without having to push malware onto the client.
Re: The solution is as obvious as it is hard... (Score:1)
If only we could roll it back to < h1 >Hello world. < /h1 >
< p > < a href="https://slashdot.org/" > Click here < /a > for news for nerds.
Re: (Score:3)
Rolling back complexity never works. However imagine the following: Static pages are transmitted by some simple, yet flexible format. Think of something like "archive grade" PDFs. For interactive applications you can simply have some TCP connection exchanging commands to change the structure of that document.
In it's most trivial form that could simply involve bitmaps, and you'd get something like RFB (a.k.a. VNC) for the interactive parts. On the other end of the spectrum you have the already existing telne
Re: (Score:2)
It's document centered design makes it hard to do interactive applications without having to push malware onto the client.
How would you do it in a way that is not document centered design?
Re: (Score:2)
Well the most obvious example are text terminals. What is transmitted via the line are simple commands that change the state of the terminal. The terminal cannot do anything remotely Turing complete. On any well defined terminal standard, there is for example no way to send the terminal into an infinite loop or to calculate a prime number.
FOSS empowers experts ... (Score:3)
... to do their job. Close source empowers corporations to make obscene amounts of money off of clueless customers. That's the way it is and always has been.
It's up to each expert and clueless customer which game they want to play. I made my decision for FOSS in the late 90ies and haven't regretted it a single day.
FOSS doesn't need to evolve, FOSS needs to remember what it means to be FOSS and stick to it. Things will turn out just fine if it does.
Re: (Score:2)
It's not a clear cut choice. Yes, I decided to switch to GPL software back before Linux had a decent word processor, and I've been happy with the switch, but the threat level *is* increasing. Partially it's because so much software is self-updating over the web, or depends on external code repositories. That allows any penetration spread to spread rapidly. And partially its a "cost of success". MSWindows people always said "The reason Linux doesn't have any viruses is because nobody uses it." and they
Article Selection? (Score:5, Interesting)
So I can't help but wonder how an article that is generating so much critical commentary was selected in the first place.
Is this another case of the new slashdot editors intentionally bypassing the voting process and picking "click-bait" articles to generate site traffic? It sure looks like it. The article they chose in this case is pretty much nonsense.
For example, the crux of the article seems to be expressed with the statement, "The net result is that projects of the scale and utter criticality of the Linux kernel aren’t prepared to contend with game-changing, hyperscale threat models." Yet to illustrate this, the author also claims "The biggest open-source projects now present big targets" and then goes on to qualify this statement by saying,
"They are evolving to commodify each other. For example, it’s becoming increasingly hard to state, categorically, whether “Linux” or “Kubernetes” should be treated as the “operating system” for distributed applications. For-profit organizations have taken note of this and have begun reorganizing around “full-stack” portfolios and narratives."
This is a bit like saying, "Inappropriate use of drywall as a structural component is threatening the strength and integrity of housing in the United States!" and qualifying this statement with, "For example, with electrical appliances today being fitted with longer and longer mains cables, it is increasingly hard to state, categorically, whether the in-wall cabling of a property or the mains connection leads should be treated as the "electrical system" for portable appliances..."
Utter tosh.
The article's author, Sean O'Meara, works for a company called Mirantis, who look to be some form of Kubernetes-aligned VAR. Interestingly, if you go to the Mirantis web site and look at "Meet the Team [mirantis.com]" , there is no sign of any "Sean O'Meara" there. New hire maybe? Wanting to make an impact maybe?
Re: (Score:2)
The article they chose in this case is pretty much nonsense.
it indeed is.
also, betteridge's law of headlines [wikipedia.org] could have tipped you off.
Re: (Score:3)
Re: (Score:3)
But that was the case when Slashdot was run by Rob Malda and his friends, before he sold the business.
The difference now is that ever since it was taken over, the quality of the article selection process seems to have suffered. While we might agree that selecting clickbait stories to post might generate a bit more traffic in the short term, it is also sad-but-true to note that more and more thoughtful contributors are giving up and the sight is slowly sliding downhill in term
Re: (Score:2)
This is a bit like saying, "Inappropriate use of drywall as a structural component is threatening the strength and integrity of housing in the United States!" and qualifying this statement with, "For example, with electrical appliances today being fitted with longer and longer mains cables, it is increasingly hard to state, categorically, whether the in-wall cabling of a property or the mains connection leads should be treated as the "electrical system" for portable appliances..."
After RTFA, I would say his argument is more along the lines of:
Poplar has evolved to become an alternative to pine for housing structure. The methods used to vet builders worked for a long time, but as it became more popular and used for more complex construction, there are some flaws in the process. We never saw a need to change because we never had termite problems, unlike pine. We used to trust builders who helped build several buildings and allowed easier them access to future construction sites, bu
Re: (Score:1)
The headline could've told you that. This is an opinion piece, so a honest headline would have been "Opinion: The open source movement needs to evolve." Making the thing a question (to which the answer inevitably will be implied to be yes but barring very few exceptions turn out to be no) is obvious clickbait.
This raises (not begs) the question of what makes (this so obviously) clickbait. A fair summary might be dishonesty. It just so happens that nerds tend to dislike dishonesty. So, habitual clickbait i
Re: (Score:3)
For me it gets a lot of response because the headline is obviously correct, but the body of the text is the opposite. So I try to think about how the evolution *should* happen.
(OTOH, regardless of "should", it *will* evolve. Evolution doesn't stop. And it often heads in a direction that many, or even most, people would prefer it didn't.)
Betteridge's law in full effect (Score:2)
Found it! (Score:2)
Found the real motivation.
Glad I'm not the only one... (Score:2)
it's becoming increasingly hard to state, categorically, whether "Linux" or "Kubernetes" should be treated as the "operating system" for distributed applications. For-profit organizations have taken note of this and have begun reorganizing around "full-stack" portfolios and narratives.
Yes. (Score:1)