I paid for my university education, in that I paid an institution for access to its faculty and for use of its facilities. The knowledge was free; all I had to do was take advantage of the fact that it was there for the learning. I've told many people about things I learned in school. I didn't need to pay a license fee to tell other people about Hamiltonian mechanics or Gödel incompleteness. The academics who created this body of knowledge published papers and gave away their knowledge. As far as I'm concerned, I got something for nothing from them.
Michael Faraday discovered electromagnetic induction and thereby paved the way for the electricity and electronics industry. The value he captured from this development was nowhere near all the value he created for everyone else. Such was his station in life. He made the choice to freely give his time to the advancement of science. Many others have followed his example, but nowhere near a majority. Yet this tiny fraction of people has exerted a significant, disproportional change on the world. Such is the fate of certain knowledge workers. Get used to it.
On first blush, software appears to follow this academic pathway. Yet software has users, who must find the software useful to keep it. Researchers do not have to make their output useful, just accurate, novel and potentially useful. To wit, researchers don't have to do market research. Clearly, software developers don't think they have to understand their users. Developers need to understand their users only when they expect to have users.
The distribution of software clearly follows the model of academic knowledge—create it once for free, then make the user pay for its distribution. Yet the creation of software does not mirror the creation of knowledge quite so accurately. The principle of “academic freedom” is about as antithetical to the principle of “attaining user benefit” as possible. The two just don't fit and can't. The university never had a monopoly on creating knowledge—or on developing free software—and it never will. The university, however, does embody the understanding that some development requires nurturing that cannot be easily obtained elsewhere. Software development has no such analogous institutions, and it needs one that is not the university.
This new institution should be a non-profit, tax-exempt corporation especially created to pay for the design, construction and delivery of public software. Let's be obvious about this: giving away software for free is about as close as possible to the center of the charitable purpose requirement of a tax-exempt company. Like the university, the staff—no, let us call them the talent—the talent working at this institution are not motivated by dreams of entrepreneurial riches, but by the advancement of the craft. The talent needs to come from a wide variety of disciplines, essentially all that are present at a for-profit software company. This new institution will always be in competition with commercial interests for talent, so it will have to pay for talent accordingly. Talent gets paid, the institution creates some well-needed feeling of solidity, and regular folks get free software.
“Public software” is any software that people can obtain and use without any entanglement with intellectual property issues. Public software also denotes the ubiquity of the software and the corresponding expectation that people encounter it frequently. Some open-source software is public software, some is not. Public software is a concept rooted in the nature of its end use, not in the means of creating it. All the wrangling over license terms for derivative works has obscured the obvious point that the license is in service of some goal; if you don't name your goal, you can't possibly attain it. I know what my goal is—it is free beer.
I still can't figure out how the claim that the GNU Public License encourages free speech is not utterly disingenuous. The GPL is the opposite of free speech; it's a highly detailed copyright agreement with the purpose of restricting the expression of derivative works. If I can't keep an expression to myself, I am restricted. All license agreements begin from the starting point of complete restriction, that is, total prohibition against use, and then work forward from that point. The summit of free speech is public domain expression—if you want to speak it again, go ahead, and for whatever purpose you care to seek. As much as I am an advocate of free speech and all other civil rights, my purpose with public software is not free speech—it's free beer.
The crucial reason the GPL has achieved such limited success in scope is that its purpose is to benefit programmers who want access to code, not to benefit outside customers. Whatever benefit an outside customer gains is ancillary to the benefit to programmers. This observation also explains why most GPL code is in development tools and environments. To be blunt, the GPL is a selfish contract for selfish purposes which cannot possibly be generalized.
The open-source model, by contrast, is a technique in search of goals. Open Source encompasses the goals of the GPL, and indeed found some of its initial inspiration there. Yet Open Source also encompasses other disparate goals, such as those for Mozilla. I want to promote Open Source, but as part of my desire to promote public software. My goal is compatible with Open Source, but I seek Open Source not to promulgate its own merits, but as an enabler of public software. Indeed, I fear sometimes that the Open Source movement may fall to the hazard that is the core selfishness of the GPL. In an attempt to seek openness, its promoters may forget that, whatever benefit they derive from access to code, they must place benefits to users first. By avoiding that hazard, I am confident good results will come from the hubbub of activity surrounding Open Source. I wish them well, but their effort is not identical to mine. My effort is toward public software.
The natural venue for the release of public software is the new institution. The value of any software derives in large part from the solidity and gravity of the organization that creates it. Ferreting out those expectations about the future which affect the net present use value of software is another essay. Let me observe, without justification, that people overwhelmingly prefer code that is stable, architecture that is well-designed, products that can be repaired and upgraded, and companies that will endure. Most people lack the means to evaluate technical merit in software. Even more people prefer to do things other than evaluate software. For almost everybody, one's expectations about the institution stand in as a proxy for all that thinking. Since I want public software to become ubiquitous, I want the new institution to ship product.
I have not yet mentioned sustainability of the new institution, because concerns about sustainability are concerns about means, not about goals. A coherent and organizing focus on what needs to be accomplished has been lacking; instead, we have had endless fretting about how to do it—whatever this “it” is. For all of its faults, at least Richard Stallman elucidated a clear goal for the GPL: “Make all source code everywhere usable by me personally.” A selfish goal, but at least it roused the mutually self-interested to action. I cannot name another general goal that has inspired more coherent effort in this area. There has been much agreement about techniques, but I have seen no successor—in goals—to the free software manifesto and the GPL.
Nor do I want a single successor. I want to see many inspirations for creative technical work. Some may overlap; some may conflict—this is of no matter. I want to see manifestos that exult in the clarity of their vision. I want to see new approaches conceived in the understanding of the obstacles to victory. Here, for example, is one such possible goal for Linux:
I want Linux to be the only conceivable choice for every commercial and personal use of operating systems. I want universal device support, instant installation, zero administration and a completely correct implementation.
We will know we have succeeded when Microsoft's market capitalization suddenly drops to exactly its cash balance.
No institution can survive on a single goal, for when that goal is accomplished, the purpose of the institution fades. The life spring of an institution, that whence all material support arises, is the stream of specific purposes that passes through it. Universities achieve this with tenure and academic freedom. The new institution, for its existence and its continuation, requires this same kind of stream of purposes. I want software for nothing; thus I require cooperation with others.
Given my goal of just-use-it-ware, I propose the means of a new institution. As a means to a means, we now have to examine the grungy underbelly of institutional sustainability. Or, to wit, who pays? If you grant the desirability of the goal (no-fee software) and the usefulness of the means (the new institution), then we need not become spooked when we discover sustainability is hard. Once we know our goal, we may persevere in seeking it and not be distracted by less attractive or undesirable goals.
The first, almost too-obvious place to look for resources is the existing network of public and government money that funds such non-profit endeavors as public broadcasting and particle accelerators. No one can do this alone. Who would give a few million dollars to a hastily organized bunch of technical guys who look suspiciously like the “Hacker Development Environment League”? If the point of the institution is software that benefits the public directly as a whole (and not indirectly, with compilers), then we need representatives on the board who are believable and legitimate to the various constituencies who might provide funding. That means people outside the computer industry.
As a rule of thumb, the university takes one-third of each grant to support the institution. This is simply the necessary overhead to have an institution and not just a group of researchers. Rather than worrying about the shibboleth of “efficiency” of the grant allocation, accept that the very existence of the institution is of separate efficacy. The institution creates value—value in solidity, value in stability, value in longevity—that individuals and informal groups can never provide. The total value of software is far more than the actual running code. Software of uncertain provenance and indeterminate future is mostly worthless. If you disbelieve this, go look at market share estimates. Put an institution behind that same code and it suddenly becomes valuable. To be generous, maybe one-quarter of the total value of software comes from the product. We can get the other three-quarters value from an institution and pay for the institution with only half the money we spend directly on talent. Still worried about efficiency? Three times the value for half the money, and institutional maintenance is looking six times more productive than the talent.
It's not that the developers are unproductive. The mythos of the hacker community rests in the power of a small number of programmers to change the world. When put this way, the effort is discrete and the change is instantaneous. In other words, the formulation is one of magic, not of economics. Extensive change comes only from sustained effort by numerous people with aligned goals. Unless there are people who nurture the project without interruption, these efforts at change wither and become of no consequence. Those who have set their lives around the mythos of the magical coder urgently need assistance in completing their work. I believe in this mythos. I do not identify it as magical in order to kill it, but rather to feed it. The new institution I advocate herein is a completion of the creative spark at the heart of all good software.
The activity here is not merely inventing such mechanisms and analyzing them, but also mounting experiments. The institution needs fiscal solidity in order to have the confidence to attempt new forms of support.
A first, concrete funding goal would be to build an endowment fund. Rather than endowing a chair in which a single researcher sits, I want to endow a table around which a release committee shall meet. Here's a specific beginning goal for such a new institution: a $25 million endowment for the Linux Release Table. The residual investment income would be adequate for five members of the table, two paid interns and two administrative staff members, all full-time positions. This table would not do any technical work, but would coordinate planning, architecture, development and release. Now this table could not possibly encompass the breadth of activity generated from a ubiquitous, dominant Linux; clearly, more people and more money and more structures would be necessary. Yet this first endowment could be the seed of a full set of institutional structures surrounding Linux.
The focus on endowed tables for release is one of the lessons learned from the open-source world and from Java. Namely, who matters more than how--the party who releases new versions of a product matters more than how the license terms read. The new institution needs to focus strategically on branding and compatibility as keystones to generating value for users. No matter what the licenses for intellectual property are, the association of the institution with the product is the critical element in delivering the value of the institution. Branding is the manifestation of this association and is the initial point of its delivery. Compatibility prevents pollution of the brand and thereby ensures its longevity. Trademark licensing enables control of the brand and subsequent control over compatibility. Sun has masterfully demonstrated with Java how to pull off this trick. How much better if one of the new institutions had pulled it off instead!
I have suggested a new institution; I also suggest a new idea for an institution. A mature field of public software creation could not subsist on a single organization of this new type. No initial efforts in creating these new institutions should be taken as an excuse to defer one's own effort away from building a “competing” institution. The principle of the new institution is public and cooperative, not singular and nepotistic. I should hope for jockeying for position between institutions, only as a convivial process of mutual betterment.
The average Joe wants something for nothing. With knowledge and information, we can come as close as possible to this ideal. Let the scarcity economists haggle over flesh. We won't appreciably change GDP figures. The new institution is an exercise in abundance economics. Free knowledge and information add untold real wealth to the world. Let our revenge upon scarcity be that its limitation upon wealth become miniscule.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Tech Tip: Really Simple HTTP Server with Python
- Doing for User Space What We Did for Kernel Space
- Rogue Wave Software's Zend Server
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide