In the form of provocative statements against which a panel of Greybeards and Elders could react in a plenary session. presented in the style of Nine Point Five Theses.
1. On the continued inability to make a living “performing” Open Source
There have been a few very notable failures in Open Source of late which have been attributed to the inability of anyone (anyone at all) to fund the continued development and maintenance of the critical componentry of the internet. The failure to fund has manifested in the core contributors being unable to fund even a meager lifestyle based upon their work in Open Source. One can point to openssl (as a group of individuals) , pgp (gpg), ntp , at least. One can assert that this is “all different now” with the Core Infrastructure Initative , but is it? Why?
- Tech giants, chastened by Heartbleed, finally agree to fund OpenSSL; Jon Brodkin; In Ars Technica; 2014-04-24.
Teaser: IBM, Intel, Microsoft, Facebook, Google, and others pledge millions to open source.
- The Open-Source Question; In Slate; 2015-02-12.
Teaser: Some of the Web’s most important infrastructure is barely funded. How can we preserve it?
- NTP’s Fate Hinges On ‘Father Time’; Charles Babcock; In InformationWeek; 2015-03-11.
Teaser: The Network Time Protocol provides a foundation to modern computing. So why does NTP’s support hinge so much on the shaky finances of one 59-year-old developer?
- Core Infrastructure Initiative
- OpenSSL, OpenSSH, NTP Get Funding From Core Infrastructure Initiative; Eduard Kovachs; In Security Week; 2014-05-30.
2. Open Source is priced right (free) because testing is omitted (end-users, consumers, are the testers)
One claim about open source software is that it is so cheap (free) because the quality is commensurate with the price. With all bugs being shallow to the many eyes , then every consumer becomes front-line on the quality assurance team. Similarly, the criticism from the pundits follows the line that “if someone isn’t paying you to do it, then it is a hobby.” Now we are hearing that the cost and efficiency gains of opens source software is being replicated in the hardware realm as well , namely cutting the cost out of the system by making the end users do the testing; i.e. skipping the testing cycles altogether. With hardware and software combinations being increasingly composed into (human-)life critical applications, this seems like an unwise direction. Should one use, could one use open source in a home automation rig, in a drive-by-wire car, fly-by-wire airplane, in a power plant, in a nuclear power plant? Are there still areas where the open source model is still not appropriate; i.e. where quality “really matters” or where trade secrecy really really is important because(lives are at stake, property is at stake, “think of the children”, etc.).
- Linus’ Law; In Jimi Wales Wiki.
Stated: “given enough eyeballs, all bugs are shallow”; restated: “Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix will be obvious to someone.”
Attributed to Eric Raymond, The Cathedral and the Bazaar, 1999.
- Open Compute Project testing is a ‘complete and total joke’”; Chris Mellor; In The Register; 2015-07-07.
Teaser: Source questions integrity, neutrality of certification programme
3. Graphics in Open Source is second class, by corollary X11 will never be bettered, will it?
Why is that the open source world has never produced a successor to the graphics stack of X11? A view is that if one wants “kickass” graphics, one has to go closed source (i.e. Microsoft with Windows drivers). One is always hearing that there are new improvements to the open source versions of various graphics drivers, but that they are a ways off from the baseline (i.e. from Windows). One hears about fewer total, utter unworkable incompatibilities nowadays, but the essence remains: the closed source stuff is “better.” Why?
4. Open Source has been captured by copyrighting the very APIs that it uses
Apparently from legal jurisprudence, one can create and copyright Application Programming Interfaces (APIs) within a programming language. Is it still reasonable to believe that one can create valid open source based upon such closed interfaces? Of course, I’m thinking about Android’s application interfaces being based upon Java whose owner has asserted various copyright claims. Is it not unreasonable to believe that “true open source” cannot be written in terms of “locked APIs?” Wasn’t guarding against just such an eventuality as this the whole impetus behind the open source movement in the first place?
5. Open Source OSes live at the behest of BIOS and Unified Extensible Firmware Interface (UEFI) will squeeze it away
What will become of the open source operating systems when their boot images must be signed with a Microsoft key? <quote>Microsoft refuses to sign binaries distributed under certain open source licenses, including the GPLv3, which GRUB 2 and rEFInd both use.</quote>The “shim trick” seems like a slim kindness that will go away at some point, and soon. Is it not unreasonable to believe that at some point they will longer allow [your] work to boot on available hardware? A rebuttal could be that open source could live on within virtual machine containers, but that doesn’t feel very comforting.
- James Bottomley; Linux Foundation Secure Boot Released; In His Blog; 2013-02-09.
- James Bottomley; Adventures in Microsoft UEFI Signing; In His Blog; 2012-11-20.
- Microsoft UEFI Certification Authority; Jeremiah Cox (Microsoft); At UEFI PlugFest; 2013-09-19; 25 slides.
- UEFI Secure Boot: Big Hassle, Questionable Benefit; Carla Schroder; In Linux.com (Magazine); 2012-06-12.
- Matthew Garrett; UEFI Secure Booting; In His Blog; 2011-09-20.
6. Closed Source has money and they Play Rough
Consider the case where an open source project achieves success and a large user base only to be taken “off the market” by a closed source competitor. Not immediately of course, but slowly over time the open source (community version) drifts and atrophies. I’m particularly thinking of the MySQL case here, but there may be others. Is this just fair game in the art and science of businesses in a closed-end marketplace?
Like crabs in a bucket they are…
systemd, upstart, sysvinit, /etc/rc.local? Tomato-tomaaaato, let’s call the whole thing off. Don’t you [panelists] think that this sort of squabbling keeps open source software “small” and “hobbyist?”
8. Open Source has hit ‘Peak Toolchain’
On counterpoint though the Java culture folks will point out that with their JIT compiler, VM technology and multi-tenant mega-container client-server architectures (J2EE), they simply don’t run into the class of problems that Docker and container systems attempt to address. No remediation needed, they just don’t have the problem.
So a question to the panel is whether the open source operating system world has hit “Peak Complexity” and every move after this is merely saving off the ultimate collapse of the whole regime. Even Koji, the Fedora build system is really a sourdough system where one must seed the system with the packages & components of the last known working release and build/rebuild to a fixed point in the new stack (kernel, glibc, systemd, service daemon, applications, window system, etc.).
The original reference is 18 months old and the direct criticism may have been addressed. Red Hat now sponsors has Project Atomic (Atomic App, Nulecule, Atomic Host).
An appropriate response to the direct technical criticism of Docker in a 5-min response from a panelist would be that these are the normal teething pains for a new technology. They should be more solid in the future. “Let’s move on.” But the greater criticism of addressing dependencies and complexity to stave off impending collapse is worthy of a plenary panel.
In real life … best to wait until these get solved, and the nested, nasty dependencies only get worse.
For example, we have today’s emergency-mode announcement from OpenSSL of CVE-2015-1793 (2015-07-09) that they have repudiated OpenSSL 1.0.2 and prior outright and that the whole wide world of the internet must upgrade to the new code that has no bugs. Yet for most systems, it simply isn’t possible to “upgrade” because of the dependency issues, we will have to upgrade from bare metal upwards to get access to the new OpenSSL, and that means upgrading storage systems, databases, networks, and applications. Some systems just won’t be upgraded.
- Alexander Larsson; Adventures in Docker land; In GNOME Blog; 2013-10-15.
<quote>Unfortunately Docker relies on AUFS, a union filesystem that is not in the upstream kernel, nor is it likely to ever be there. Also, while AUFS is in the current Ubuntu kernel it is deprecated there and will eventually be removed. This means Docker doesn’t run on Fedora which has a primarily-upstream approach to packaging.</quote>
9. An Open Source strategy is basically “beggar thy neighbor”
There exists thinking in technology strategy circles, and in cocktail party circles (same thing really, no?), that Open Source is a weapon that must be used appropriately and sparingly. The thinking runs like this:
Use open source
- for the peripheral competency of your business; think: operating systems of “the cloud.”
- to devalue the core competency of your competitor’s business; think Hadoop vs (Google)MapReduce.
Use closed source (trade secrets)
- the core competency of your business; keep how you add value to yourself.
This mode of thinking explains much about open source and how it behaves in the marketplace. Rebut, assent or explain.
9.5 Software-as-a-Service (SaaS) is just a way of packaging Open Source, now isn’t it?
Somewhat of a softball here. SaaS forces payments to happen on a regular basis. But also the thinking is more aligned with Peak Toolchain concepts.