Industry Watch: Linux for Real
I was kind of sad when Webvan went chassis-up. Webvan trucks had become a common sight in my old neighborhood, and the company really did offer a good service. Their food was always fresh and carefully delivered. Their drivers were always friendly and helpful. Their prices were even pretty competitive. They just didn't have what we now call a business model. Translated from the Euphemese, a business model is a way to make money. It turns out they never had one, and investors spent $.83 billion exploring that possibility before declaring Chapter 11 in July 2001.
Once again the obvious was not apparent. The obvious is this: if you have to explain your business model, you probably don't have one.
I'm not sad at all to see various ``exchanges'' and other ``disintermediators'' fall into hard times. Like Webvan and other e-tailers, their creators and funders were smitten by the efficiencies of the Net. Those efficiencies, however, appear persuasive only if you see the Net as a way to distribute goods and shorten communication channels between ``economic actors'' and other abstractions. That point of view made sense through most of the Age of Industry, when we came to see business as a vast delta of value chains that fanned out from a few producers to a zillion consumers.
Making that system more efficient was nothing more than economics at work. And economics understood itself largely in terms of activities on the supply side of the supply/demand relationship. That's why it has become nearly impossible to talk about business without borrowing the language of shipping (e.g., moving goods, adding value, delivering service, etc.).
So big producers and their wannabes always become excited about possibilities opened by abundant new resources and more efficient distribution systems. The Net provided both in such surfeit that opportunists went insane fantasizing about the possibilities. I remember Jim Clark interviewed on public TV about Netscape's opportunities in its earliest days. He said something like, ``We had seven million users! There ought to be a way to make money with this!'' Those users were attracted by something that was very useful but also free. Only those users' loyalty and affection for Netscape made it possible for the company to start charging for its browser. And that's why the most strategic thing Microsoft did with its browser was give it away for free, instead of tying it to Windows. (In a controlled study, Microsoft's browser wasn't tied to the Mac OS, and yet it became the most popular browser on that platform as well.)
The bigger you are, the more expensive your lessons become.
As I write this (in mid-July) a $1 million study by the Markle Foundation has just delivered this bit of news:
By far, the leading metaphor for the Internet, in the public's mind, is not ``a shopping mall'' or ``banking and investment office'', but rather ``a library''. Despite the popular depiction of the Internet as a channel for commerce, the public mostly views it as a source of information, and these uses appear to explain its popularity much more than its utility as a way to shop, bank or invest.
What that passage fails to mention is that the primary sources of information on the Web, in pure bulk volume, are not big publishers or any other kind of big business content providers. They're other people. Which brings us to Linux.
For production-minded business folks, Linux has the same problem as the Net and, by extension, as the nature of software itself: it's free. In other words, it grows all over the place. You can take all you want and use it pretty much anywhere you want. ``It's not that it grows on trees'', my friend Arne Flones says. ``It's that it is trees.''
Think of the situation in early America, when lumber was everywhere for the taking. There was hardly a more American myth than Paul Bunyan, the giant lumberjack who glorified the shearing of wood from wilderness. The difference between Linux and lumber, of course, is that you don't need to kill any trees (or even any software companies) when you harvest and hew Linux into useful building material.
It's also no accident that in software we borrow the vocabulary of construction. We design, architect and build software. In fact, we can hardly talk about software without talking about construction. So, is the software industry turning into something like the construction industry? I think so, but it's still early. Software is a few decades old at the most, while construction is as old as civilization itself. But the construction industry we have today shows where we might be headed with software, especially embedded Linux.
In construction there aren't many secrets about building materials or building methods. Open source is a standard concept. Practitioners share their knowledge and skills for the good of the whole business. When somebody finds a better way to hang a door or put up drywall, the insight gets passed around. The difference, of course, is that software-building knowledge gets passed around the Net, so knowledge spreads like wildfire.
Construction is also about a $2 trillion industry worldwide. It is perhaps the largest, most developed and least centralized industry in the world. It has no Microsofts, even though it includes companies with revenues larger than Microsoft's. Think about that.
Thanks to the Microsofts of the world (if we can risk referring to a monopoly in the plural), most of us--especially those IT folks my Linux Journal column calls suits--still tend to think of software as a manufacturing business. Yet Eric S. Raymond reminds us that most of the software we write is not for sale. More of it has use value than sale value. ``In other words'', he adds, ``software is largely a service industry operating under the persistent but unfounded delusion that it is a manufacturing industry.''
Maybe so. But Linux's abundance is less significant to the software companies that harvest it than to the manufacturers who put it to use. To those people (that's you, our readers), Linux is a universal building material that only becomes more useful as more builders learn and share what they know about it. It's a mass that went critical a while back and only continues to boom. There are other free and open operating systems out there, but none that people work with and talk about as much as Linux. So Linux only gets more and more embeddable.
What's important to recognize here is that the vast majority of manufacturers in the world--both of software solutions and of the hard goods built with embedded software--aren't big-time producers. Those producers matter, which is why it's good to have the TVLinuxAlliance for settop box design. But, as with the Net's library, the most abundant source of information about embedded Linux is the set of experts with passions that inform our own.
The Nigerian biblical scholar Sayo Ajiboye tells me we can understand real markets--bazaars--in terms of two different conceptual frameworks: exchange and relationship. It is the latter that provides the context for the former, he says. Here in the industrialized world, with its preoccupation with moving the goods and the bottom line, we devalue and ignore the importance of relationship--especially of what experts tell experts about the kinds of work they both do.
Now we're reading about how pure exchanges between letters of the alphabet (e.g., B2B and B2C) are failing for the simple reason that they exclude the very context they need in order to work in the real world. Working with Linux in the embedded space requires experience and expertise of many different, specialized sorts. It helps that we have a place where we can obtain both, quickly and easily. It also helps that we made it ourselves, and that it's wide open and free.
It looks like the Net, but it makes more sense by two older synonyms. Linux hackers call it the bazaar. The rest of us call it the market.
Doc Searls is senior editor of Linux Journal and coauthor of The Cluetrain Manifesto. His next book will be Real Markets: What They Are and How They Work.
Doc Searls is Senior Editor of Linux Journal
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!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Tech Tip: Really Simple HTTP Server with Python
- Managing Linux Using Puppet
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
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