Troubleshooting Professional Magazine
|
Birth of a Book |
|
|
At 300+ pages and 117,000 words, it wasn't easy to write. Making the job even harder was the fact that I recently switched from the Windows operating system to the GNU/Linux operating system, so most of the tools I used to create "Rapid Learning: Secret Weapon of the Successful Technologist" were unavailable. And yet this book turned out to be the best produced book I've ever done, with more consistent styles, better typesetting, and for the first time in any Troubleshooters.Com book, an index. Excluding the staple bound cover, this book is aesthetically beautiful.
How did I manage such professional publishing using only Open Source software? Which tools did I use, and how did I use them? What challenges needed overcoming? And what does this say to those who claim you can't make money with Open Source?
The answers to these questions are contained in the articles of this issue. So kick back and relax as you read this issue. And remember, if you're a Troubleshooter, this is your magazine. Enjoy!
I learned how to quickly write a full sized book while writing chapters for "Red Hat Linux 6 Unleashed" in 1999. A quick look at the tables of contents and chapter contents of several Unleashed books confirmed my suspicion that these books were written from outlines that went six levels deep (about as deep as you should ever go in a book). After finishing my Macmillan work I made a 940 headline outline, in MS Word, for a book to be called "Rapid Learning: Secret Weapon of the Successful Technologist", and wrote the book in 2.5 months. This book was twice the size of my first book, and took less than a fourth of the time. Full outline design prior to writing had proven its worth.
So as the main author of "Samba Unleashed" in 1999, my first step was to spend an entire month outlining the book. The outline turned out to be 2800 lines long. Was it worth it? I believe so. Once the outlining was done, the writing process took between 3 and 4 months for this 1200 page book. I wrote over half the book myself. And if you look at the reviews of "Samba Unleashed" (see URL's section), it's obvious that everyone liked the content, structure and organization of the finished product. Outlining had proven itself.
After switching to Linux in March of 2001, outlining became a challenge. Unable to use MS Word or even anything half as good for outlining , I put off writing another book. But as the months rolled on it became obvious that the aging "Troubleshooting: Tools, Tips and Techniques" needed replacement. I created a series of configuration files and scripts to make the Vim editor into an outliner, and made a 900+ line outline for my new troubleshooting book, "Troubleshooting Techniques of the Successful Technologist". The outline challenge had been solved.
But now I was in Linux, where MS Word is unavailable. After Corel's partial sellout to Microsoft I had a serious "who owns your data" problem with any Corel product, so WordPerfect for Linux was out. Most Linux word processors weren't up to the task. The main possibilities were Docbook and LyX, neither of which were as simple as WordPerfect 5.1 or MS Word.
I'd pretty much narrowed it down to Docbook and LyX. LyX provided quick content entry and good looking output, but its facilities for style creation and modification seemed grossly inadequate. Also, LyX seemed to export only to LaTeX, PDF, HTML, Postscript, and DVI. This was a serious "who owns your data" problem. Docbook seemed the way to go.
But Docbook had its own problems. I could have used Emacs to front end my Docbook, but I don't know Emacs and have had trouble trying to learn it. LyX can front end only the SGML version of Docbook, and I wanted to use the XML Docbook representation, so a LyX front end for Docbook was unsuitable for me. Most other Docbook front ends required tag coding, which is a productivity killer for a writer. The moment you switch your focus to coding a tag, you forget the idea about which you were writing. Ughhh!
The decision came when I looked at a LyX document in VI. The LyX native file format is simple, easily understandable and parsable, and you can recover all styles. It would be trivial to write an app to convert LyX code to XML.
The decision made, it was now necessary to evaluate LyX to make sure it would do everything needed. Nobody wants to be half way through a book when they discover their authoring software won't do the essentials.
Already knowing most of the terminology, I started by seeking a "Hello World" environment (LyX paragraph styles are called "Environments"). It's NOT the slightest bit obvious. I finally learned to create a new environment (call it MyStyle) by placing a file called MyStyle.layout in the .lyx directory under my home directory, and then in LyX choosing Edit->Reconfigure from the menu, and then restarting LyX. If you're interested in what goes in that file you can see my "Writing Books with Lyx" page at http://www.troubleshooters.com/linux/lyx/index.htm.
I found out the layout file could be placed in the same directory as the document, and then place a symlink of the same name in the .lyx directory under my home directory. In this way I kept everything contributing to my book in one directory.
Soon I learned to modify not only the appearance in LyX, but also by using LaTeX I could modify the appearance in Postscript and other outputs. Now Paragraph styles were within my reach, although throughout the writing of this book style mods and adds remained difficult.
The evaluation uncovered the true nature of LyX. It's a front end to the LaTeX typesetting language. LyX markup and LaTeX markup look remarkably similar, which would haunt me throughout the writing of this book, and indeed haunts many people. If I do one thing for the LyX community, it will be to correctly and simply document when you use LyX markup, and when you use LaTeX.
LyX has no built in outlining ability -- at least none that would help an author design the structure of a book. I therefore created a script to convert my VimOutliner created outline into LyX headings. It worked superbly!
I tested graphics, and they appeared to work perfectly as long as they were in Encapsulated Postscript format. I neglected to test graphics in a long document, and that fact came back to haunt me on a day I call "Black Friday". But for the time being, my research indicated that LyX would be able to carry me through to a finished book. I already had my outline and a way to convert it to LyX. On August 26, 2001, I quit evaluating and began to write.
Then I wrote actual content. Unfortunately, a problem with a Chapter 1 graphic stopped me dead in my tracks.
Saturday, September 1, LEAPster Bryan Coyle solved the dilemma by telling me that this problem was a well known defect of Mandrake 8.0's CUPS implementation, and I could fix it with an update. I fixed it and began to slam out content in earnest.
The 10 days til the next crisis saw huge productivity, with several chapters written at a rate of over 4000 words per day.
But we all got back to work, and I was no exception. Slowly but surely, progress continued and the book took shape.
Two character styles were needed -- one for the book's chapter names within the text, and one for the names of Universal Troubleshooting Process steps. I probably could have used noun style, but if kludges like that were acceptable why not write the book in Notepad?
I asked about character styles on the LyX mailing list. Some of the developers mentioned that such styles would be in a future LyX release. That didn't help much, because unless I could find a way to identify such styles now, there would be no reasonable method of finding applicable text and applying the new character style. It looked bad.
Then a LyX list participant named Dekel Tsur sent an ingenious workaround. Dekel had a way to have text of certain colors attain the appearance of choice in the final rendered document. The beauty of this workaround is that when real character styles become available, a simple search/replace can be used to convert the colors to character styles. After assigning magenta to chapter names and blue to UTP step names, and coding the layout file so they both print slanted sans-serif, progress continued quickly.
Here's the problem. There is plenty of documentation for the LyX newbie, and plenty for the guru, but little in between. Newbie documentation is available from the LyX program's Help menu. This introductory documentation is quite sufficient for anyone satisfied with the default appearance of his chosen document class. If you meet someone who says LyX is easy to learn, he's satisfied with the defaults.
At the other end of the spectrum is voluminous documentation for the LaTeX expert (remember that LyX is simply a front end for LaTeX). The entire /usr/share/texmf tree contains documentation a LaTeX expert can use to create the exact appearance of his desire. But these documents have no LyX context. They say what codes to put in, but not what file to place them in, or where in the file, or how they relate to LyX markup (remember that LaTeX and LyX markup look similar, but are completely distinct).
These documents contain few examples. The LyX website has similar problems -- all the LaTeX you'd ever want at http://www.lyx.org/help/index.php3, but little context, and insufficient examples for the person not intimately familiar with both LyX and LaTeX. The content isn't organized for easy access, and there's no search facility. It has some very useful information, but not until you've used it enough to know how to find things.
The LyX mailing list itself is excellent, but suffers some of the same problems. The people on the list are so skilled in LaTeX that they answer a question with two lines of LaTeX, never realizing that the person asking has no idea where to put those lines, or how to integrate them into his LyX layout file. Repeated queries with lots of experimentation are often required for the newbie wanting to use LyX to its fullest. Nevertheless, the mailing list is the best intermediate source of LyX information. Its archives are searchable, and if you keep asking you'll get enough info to solve your problem.
I overcame the documentation hole challenge by learning more LaTeX, by learning to find answers using reverse engineering (as discussed in the December 2001 Troubleshooting Professional), and by searching code in the /usr/share/texmf tree using grep. Also, there are some websites devoted to intermediate LyX (see URL's section).
I learned how to index from the "Extended LyX Features" (Help->Extended Features from the LyX menu), and /usr/share/texmf/doc/makeindex/makeindex.dvi. If you want detailed and challenging indexing information (IMHO overkill for a simple book), see /usr/share/texmf/doc/makeindex/ind.dvi.
Proofreading was accomplished by LEAP members Aaron Morrison and Max Lang. Both were given the assignment of finding and marking confusing sentences. They found quite a few, and I fixed them.
The next step in the end game was printing. For the time being I'm printing them on my HP Laserjet 4050. That keeps my inventory low, costs reasonable, and print quality excellent. When sales rise to the point where it's practical to print in lots of 100 I'll use a professional print shop. When sales rise to the point where runs of 5000 are practical, I'll have them done by a short run book printing outfit.
The final step, and the one I haven't done yet, is publicity for the book. Even the greatest book won't sell if it isn't known. Within the next few months you'll see this book reviewed in various newsletters and websites.
On the content front, "Troubleshooting Techniques of the Successful Technologist" is by far the most complete and authoritative documentation of process oriented troubleshooting. Part I covers the basics of problem solving, including the theory and practice of solving intermittents. Part II is a complete documentation of the ten steps of the Universal Troubleshooting Process. Part III covers advanced topics including The Attitude, observation optimization, career integration, throughput maximization, and customizing the UTP. Part IV applies the theory of the first three parts to specific technological situations such as computers, networks, software, and source code debugging.
At 117,000 words and over 300 pages, it's not a small book. The table of contents is three levels deep (part, chapter and section), and the book's index is quite complete. This is my first book with an index. I just didn't have the heart to create indexes in WordPerfect 5.1 or MS Word. LyX made it easier.
In spite of the book's size, the rigorous use of styles facilitated by the LyX software yields visual consistency throughout the book. Because LyX is a front end to the LaTeX typesetting language, the typesetting of the book is exquisite. This is a very aesthetic and readable book.
This is my first book authored with Open Source tools, and it's my best book ever, in terms of both content and format.
In one sense we succeeded. The use of rigorous troubleshooting process continues to spread. The hit and miss troubleshooting that ruled the land five years ago is very much on the run. And in no small part because of Troubleshooters.Com, most troubleshooting process being used is valid -- not consultant drivel.
In another sense we failed. The hyperpolitical pronouncements on correct troubleshooting lasted just a few months. TPM is now known more for its Linux content than for its troubleshooting content. But given the intermittence and irreparability of much of Microsoft's software, Open Source advocacy might be one of the most pro-troubleshooting acts we can perform.
I've heard that Windows XP is less intermittent than previous "user"
versions of Windows. If that's true it's great news for Troubleshooters.
However, I heard similar pronouncements early in the lives of Windows 95,
Windows 98, and Windows NT, and those products all turned out to be horrendously
intermittent once the OS had been hammered on for awhile.
|
I've never used XP, and refuse to use it for business reasons having little to do with troubleshooting. The business reasons are discussed in the Editor's Desk article of the April 2001 Troubleshooting Professional Magazine. |
The news gets even better because of the wide adoption of GNU/Linux and other Open Source software in the corporate world. Linux is rock solid, seldomly exhibiting intermittence. Its text configuration files are a breath of fresh air for the Troubleshooter accustomed to sneaking around in the Windows Registry. Linux and Open Source relieve the Troubleshooter from the licensing worries so common in the Windows world.
All in all, software troubleshooting has become saner thanks to the wide use of Open Source.
2001 was a great year for Troubleshooters.Com customers. Our troubleshooting course was vastly improved. And late in the year I published "Troubleshooting Techniques of the Successful Technologist". This book is by far the most authoritative documentation of troubleshooting process available anywhere for any price. Any technologist failing to read this book does so at the peril of his career. The early readers of this book will have a huge advantage in the career marketplace.
Era 4 troubleshooting (use of automated tools based on a troubleshooting process) did not take over the world. In fact, Era 4 troubleshooting is beginning to look like a niche rather than evolution. In hindsight it's obvious that the cost of Era 4 script authoring is just too expensive for many industries. Era 4 might have better have been named "Automation Assisted Troubleshooting Process" (AATP). I have no doubt that Troubleshooting as a whole will evolve some day, but that evolution might not involve AATP. That being said, AATP continues to make inroads in the military, the automotive industry, and other uses. If you have the skills to author AATP skills, your future is bright.
As a matter of fact, no matter what kind of troubleshooting you do, your future is once again bright. The recession predicted in the January 2001 TPM issue is weighing heavily upon us, and portable skills now make the difference between a paycheck and the unemployment line. The technologist who can correctly use troubleshooting process positions himself as one of the few indispensable "go to guys" who are costly to lay off.
The troubleshooting expert with security expertise is at a premium in these uncertain times. This is an excellent time to brush up on your computer networking and security skills.
The job market stinks, but you can shine by continuing to hone your use of troubleshooting process, while at the same time being flexible in your job title, and the exact type of troubleshooting and technology you practice.
I've heard predictions that 2002 will be the year we come out of this recession. Use your troubleshooting process expertise to remain continuously employed. That way when things get good again, you'll be first in line for the great jobs 2002 is scheduled to bring us.
And once again I will name my favorite issue and top 5 favorite articles :-).
To me, the one-two punch of the March and April issues rose head and shoulders above the others, earning them a tie for best issue. March was a soup to nuts XML tutorial with which anyone could learn XML in a day. The April issue provided a tested and detailed blueprint for moving your business to the Linux desktop.
The March and April issues were also the most visited, although the May (Working With Auto Mechanics), October (Troubleshooting with the New Support Models) and November (Linux Outlawed!) issues were also heavily visited.
2001 was a year of big issues and little articles. Most articles were
dependent on other articles. But some articles managed to rise to the top,
including what I consider to be the top five:
| Article | What It's About | |
|---|---|---|
| 1 | Simplified
Explanation of the DOM API
(March 2001) |
This crystal clear tutorial on the sometimes murky subject of XML claims top honors for 2001. |
| 2 | Editors
Desk
(April 2001) |
The one irrefutable reason to switch to Linux, hammered home by a simple phrase. |
| 3 | Tales of Mechanics
Good and Bad
(May 2001) |
A series of car repair stories, each illustrating a point vital to the consumer. |
| 4 | Distinctions
(December 2001) |
How to make breakthroughs in troubleshooting and life using distinctions. |
| 5 | Linux Log: Open
Source as Consumer Revolt
(October 2001) |
A Jurassic Park analogy to the rise of Linux. |
And because this is the five year anniversary of Troubleshooting Professional
Magazine, I'll list my ten favorite articles of the past five years:
| Article | What It's About | |
| 1 | Gavin Gray
(November 97) |
This troubleshooting short story about a late-blooming baby boomer is still by far my favorite TPM article. |
| 2 | Simplified
Explanation of the DOM API
(March 2001) |
A top-notch tutorial for an absolutely fascinating technology. |
| 3 | The Man Who Banned
General Maintenance
(February 1998) |
A Troubleshooting short story encompassing three generations, over 30 years, plots, intrigue, corporate takeover, and sweet victory. |
| 4 | Problem
Solving Principles
(December 2000) |
This article gives a remarkably thorough treatment of general problem solving principles. |
| 5 | The Loser
(February 2000) |
The ultimate rebuttal to those asserting that troubleshooting cannot be taught or learned. |
| 6 | Editors
Desk
(April 2001) |
The one irrefutable reason to switch to Linux, hammered home by a simple phrase. |
| 7 | Barbarians At the Gates
(May 1998) |
An early prediction of Microsoft's Demise |
| 8 | The Woods
(March 2000) |
A compelling explanation for Step 9: Take Pride. |
| 9 | Linux Log: Where
Have All the Heros Gone?
(May 1999) |
A short but inspiring article about Open Source. |
| 10 | If you're not
part of the solution
(January 1998) |
A horror theme and a snappy ending punctuate this essay on troubleshooting process. |
A warm thank you for a job well done goes out to this year's sole guest author, Phil Barnett, for his July 2001 article, "LEAP-CF Linuxizes Central Florida at CTS Orlando".
Especially guys like me, who buy no proprietary software. It's not because of the price. If you read the April 2001 Troubleshooting Professional, you know that my reason for avoiding proprietary software is the "who owns your data" factor.
As a free software kind of guy, I didn't expect much from XML2001. After all, Bill Gates has managed to portray XML as a Microsoft technology. Expecting a bunch of proprietorists hawking expensive software with narrow vertical appeal, I walked in the door, and at first glance it looked exactly as expected. But then I began finding diamonds...
If you enjoy thinking, Ontopia's The TAO white paper is a must read (URL in URL's section). It describes the structure and power of topic maps in as simple a manner as something this general and powerful can be described. You can then use Omnigator to learn topic maps, which will almost certainly improve your mental abilities.
ActiveState developer Eric Promislow began describing their Komodo tool,
which he demonstrated as a realtime XSL debugger. At first I wasn't too
interested because Komodo is proprietary software, even though version
1.1 is free for "non-commercial use", meaning "in a teaching or learning
environment only" according to their website.
| Note: You can also purchase a non-commercial license for their Komodo version 1.2 for $29.50. |
As Eric demonstrated how each line of the XML in the input file window is processed by the code in the XSL window, producing the (in Eric's demo) HTML code in the output window, it suddenly was clear what a tremendous learning tool Komodo is. Apply my Rapid Learning techniques using Komodo as a tool, and XSL mastery is only a few days away. Within a minute of that realization came the idea to make the February 2002 Troubleshooting Professional Magazine an XSL tutorial. Tutorials are always popular issues, and this one would be widely topical. Attending this trade show had given me the tools for a high traffic February TPM issue.
As far as I can see, there's no who owns your data risk using proprietary Komodo. Your data is in industry standard XML and XSL languages, so even if Microsoft were to buy ActiveState and try to put a hammerlock on your data, you could simply switch to another development environment and go merrily on your way. So there's no risk or downside using Komodo as a learning tool. And if you decide to use it as a development tool, the only downside is the $295/year/developer cost, which depending on what you're developing could be insignificant. You can learn more about Komodo at their web page (see our URL's section).
Excited with thoughts of a hugely popular XSL tutorial in a future Troubleshooting Professional Magazine issue, I left the ActiveState booth wearing a big smile. Life doesn't get any better than this.
But it got better...
Don's 3pm presentation seemed impossible to beat, but his 5pm presentation on XML Schema was twice as good. Don started by listing the two distinctions vital to understanding schema:
From there he demonstrated the use of the Built-in Datatype Hierarchy diagram from the XML Schema specification (url in URL's section), and how various types are derived from other types.
He then taught us the four derivation types, and the fact that extensions and restrictions were the two most important of the four. He discussed the rules of schema scoping, pointing out potential landmines
From there he plunged into the details. I left believing I can write a schema, and decided that the February 2002 Troubleshooting Professional would be a tutorial on XML Schema, thereby pushing my intended XSL tutorial back to March.
---
My education has featured over 100 teachers ranging from bad to great, but only two were spectacular. At Santa Monica College there was my advanced Cobol teacher, Mr. Little, who seemed to have a Cat5 cable connected between his head and mine. As fast as he spoke, that's how fast I learned. One might surmise that I learned so well because I was the class's top student, but in fact all the students agreed Mr. Little was the best teacher they'd ever seen.
And then there was Dr. Armington at IIT. Another Cat5 direct connection, but he taught the extremely difficult subject of transmission lines (with Smith charts -- ughh), and in that class I was one of the worst students. But even I learned everything he taught, got high 90's on all the tests, and aced the course. With a teacher like Dr. Armington the only necessity is listening.
Don Smith's 5pm presentation was comparable with the teaching performance of Mr. Little and Dr. Armington. The Cat5 brain to brain connection was definitely there. So after the presentation I asked Don how he did it. The answer was surprising.
Don felt the quality of his presentation was due more to his courseware than to his teaching techniques. He mentioned that he had recently spent nine months completing courseware for an XML course.
NINE MONTHS!
Do you think that courseware might be pretty good? And the beautiful thing is, assuming the power is in the courseware, any Isogen trainer can use that courseware to duplicate Don's results. Don is Isogen's Manager of Core Technologies Training, and my impression is that he writes most of the courseware and educates Isogen trainers on delivery and the underlying XML technology.
And based on Don's 5pm presentation, I think I know his courseware principles.
He seems to start by showing the audience the landmines, and then gives
them the lay of the land -- a kind of course map, if you will. This goes
far beyond "tell em what you'll tell them, then tell them, then tell em
what you told them". At every point, Don makes sure the audience understands
the context in which they're learning, and frequently asks questions like
"this isn't so difficult, is it?", or asks a question whose material he
had just thoroughly covered.
|
Listening to Don's Schema presentation, Don didn't seem like a genius. After all, I seemed to know the answers to every question he asked before he asked the question, even though I had no prior experience with the material. *I* seemed like the smart one. Of course, most of the rest of the audience was having an equally easy time keeping up. A REALLY smart professor would be so far beyond the audience that he'd confuse them. Right? Maybe the material was just easy.
A few hours later I bought and looked through an XML Schema book written by an XML Schema expert. It was complex, confusing, and almost unfathomable. But I already knew the material in the first few chapters. From Don's 1/2 hour presentation! The material wasn't simple at all. The reason I had known everything before Don said it was because of the bandwidth of his trainer to student connection.
Don is VERY technically gifted, and could make great money as a developer. But great developers are a dime a dozen. People who can establish a Cat5 teaching connection are ever so much rarer. But somebody who can write courseware to reproduce and scale that Cat5 connection to other trainers -- I don't think I ever met one before.
In most cases I recommend learning through the methods in my book, "Rapid Learning: Secret Weapon of the Successful Technologist" (URL in URL's section). But if what you need to learn is XML or SGML related, and you need to learn it extremely fast, and you have the money for training, immediately enroll in Isogen courses. Their URL is in the URL's section of this TPM issue.
But in these busy days you need more than fun to justify spending time at a trade show. You must gain something.
In the six hours spent at XML2001, I found inspiration for two high traffic Troubleshooting Professional tutorial issues, and learned some training techniques that can be used to improve my Universal Troubleshooting Process courseware.
Are there trade shows after Windows? You'd better believe it!
|
You don't make money selling Open Source -- you make money using it. Most explanations of "Open Source business models" have been proposed as ways to subvert the laws of supply and demand, which are based on scarcity. Most such models have failed because of the flawed assumption that Open Source is a scarce commodity, or can somehow be made scarce. In fact Open Source more resembles an abundant, self renewing natural resource. Imagine it as a fast growing weed. You don't make money by selling abundant weeds -- you make money using them. The one remaining question is how these abundant Open Source resources renew themselves, when the programmers creating them are not paid to do so (in most cases). The answer is that the programmers create or contribute to Open Source projects because they need the resulting functionalities more than they need the time they spend coding those functionalities. One might ask why a programmer doesn't sell his creation. The answer is simple enough -- he couldn't make a penny. Only Microsoft and a handful of other huge companies can make money selling software. The small programmer makes his creation Open Source so at least it won't be kidnapped, changed and monopolized by a megacorporation. By making it Open Source, he knows it will be available to him forever. And if he's lucky, others may help him code it. So the future supply of Open Source is assured. A profit motive is not necessary to assure it. There's plenty of incentive without profit. The intelligent businessperson makes money using Open Source, not trying to sell it. |
"You can't make money selling free software".
Oft repeated, it's so true, yet so misleading.
The truth: Obviously there's little profit potential selling a product whose very license makes every customer your competitor in the sale of the product.
The mislead: the assumption that selling a product is the only way to
profit from the product. It is not. You can make great money using
the product to make something you can sell.
More on the evil side, certain entrenched interests with their own agendas work to perpetuate the misleading statement that you can't make money with free software. The proclamations of Microsoft's Jim Allchin and Craig Mundie are perfect examples (see URL's section of this magazine). Such proclamations operate on the deliberate and cynical belief that the public is too gullible to realize that they can profit from using a free product (possibly as a substitute for Microsoft's offerings).
Who gets the scarce items is determined by economy. In a dictatorship most of the scarce resource goes to the leader and his supporters. In communism, theoretically the scarce resource goes to those who "need it", but in practice it goes to the leader and his supporters. In capitalism it goes to those willing and able to pay the price, and sometimes to the leaders and their supporters. The point is, economics is a tool for the distribution of scarce resources. No such tool is needed for abundant resources.
It's obvious that life is better with abundance than scarcity. It would
be wonderful if everyone had a nice house in a nice neighborhood, nice
clothes, a quality education, quality health care, and a nice car. Certainly
a quick look at poorer nations confirms that given a choice between scarcity
and abundance, abundance is best.
|
Obviously the preceding paragraph is somewhat oversimplified. If we had absolutely everything we needed, we would stagnate intellectually and physically. If gasoline were a penny a gallon we'd quickly pollute the earth. But such obvious laziness and gluttony aside, for the individual needing the resource, abundance is preferable to scarcity. Note also that abundance depends to a large degree on the economic system involved. Capitalism with restrictions on monopolism usually produces a high degree of abundance. |
Not all resources are consumed directly. Some are used in the production of other goods and services. Obviously, cheap factors of production make for more profit or lower consumer prices, or a little of both. Let's take a closer look at abundance and scarcity.
Imagine if air became scarce. It would be unaffordable to run the gasoline engine in your car. Electric cars wouldn't fare much better, because coal powered electricity, which is about 50% of our electricity, would cease for lack of oxygen. The hugely increased costs of electricity would seriously damage the profits of metal plating plants, manufacturing plants of all kinds, and large server farms.
Our gross domestic product would plummet if air became scarce. The difference between that reduced GDP and the one we enjoy with abundant air is the amount of money we make from air -- an abundant resource with no cost.
We definitely make money with air -- but nobody can make money by selling air, because its price is zero.
Expenses at factories would plummet, dramatically increasing profits. In a non-monopolistic capitalist economy, much of that profit would be passed to the customer in lower prices, which would increase sales. A good portion of farmers' expenses are energy related -- more money for the farmers and cheaper produce for American families. Server farms, huge users of electricity, would send the savings straight to the customers and the bottom line.
So abundant electricity would decrease the profit of those selling it, but would increase the profit on the whole.
Luckily, salt is dirt cheap. My local Publix store sells two 26 oz boxes of Mortons Salt for 79 cents. That's 18.658 grams per penny. At that price, McDonalds must make 6.7 Big Macs to use a penny's worth of salt.
Only a few companies make a living selling salt -- Mortons is one. But every restaurant makes money using this abundant resource, which for all practical purposes is free, to attract customers with tastier food.
When I switched to Open Source software, all sorts of opportunities opened up to me. Perhaps the best example is LyX -- a true book publishing program (and much more). I would have had to spend hundreds of dollars for a commercial program to do what LyX does, and with no "try before you buy", it's very likely I would have purchased an inferior product. So I made due with Microsoft Word -- a program not intended or suitable for writing books. Only after switching to Open Source was I able to get true book publishing software.
Capitalism is the best way of dealing with real scarcity. Land is scarce -- they're not making any more -- especially near the cities. Titanium is scarce -- if it were abundant every car would have a titanium frame. But because there's not enough titanium for such uses, in a capitalistic society titanium's price rises to meet its demand, so that it ends up used on aircraft and a few bicycle components rather than entire car frames. Under normal circumstances, capitalism does a pretty good job of taking from each what he can, and to each what he needs. The individual does what he can to fulfill what he believes to be his needs. Capitalism makes scarcity more bearable, but abundance is always better than scarcity.
Well, almost always. The only exception is for those holding a large quantity of the scarce commodity. They can then trade the scarce commodity for lots of money, which they can trade for lots of other scarce commodities, or even favors from the government. That brings us to the subject of contrived scarcity.
But some scarcity is created. Consider the scarcity of word processing software. In 1986 you could choose word processing software from Microsoft, WordPerfect Corporation, Corel, Lotus, Adobe, Microrim, and many others. Today Microsoft is the only game in town, except for the forward looking StarOffice users and WordPerfect stalwarts. Microsoft put the rest out of business using the practices of illegal monopolism (Judge Jackson's and the appeals court's words, not mine).
In fact there are three primary methods of creating scarcity: monopolism,
collusion and government interference. Microsoft has managed to bankrupt
almost all competitors, so Microsoft now holds almost all proprietary software,
making it scarce. This is monopolism. In 1973 the OPEC countries voted
to simultaneously reduce oil production, thus doubling the cost of gasoline
in a few weeks. This is an example of collusion. The US government has
created a doctor shortage by making entry
into the profession costly and difficult, and with immigration rules making
it difficult for foreign medical students to set up a practice in the US.
The extremely long US patent period gives drug companies monopolies on
their drugs for 17 years or more. It's my belief that with less interference
from the government, ordinary citizens could pay for most of their medical
care without insurance, HMO's would be a thing of the past, and most people
would be getting better medical care.
|
|
The point is this: Given human nature, holders of commodities will try to artificially make those commodities scarce. And holders of scarce commodities will try to have the government restrict sale of abundant substitutes for those commodities. Hence the posturing of Allchin, Ballmer, Mundie. Their worst nightmare is Open Source software, because it eliminates software scarcity.
And yet this common sense is being proved wrong. Open Source projects like Samba, Apache and GNU/Linux have existed for years, and are stronger than ever. Andrew Tridgell, Jeremy Allison, Linus Torvalds and the people comprising the Apache Software Foundation haven't gotten obscenely rich, but it's obvious that their Open Source participation has been good for their careers.
At this point a skeptic would mention that the people in the preceding paragraphs were the Generals of Open Source, and that the foot soldiers didn't make a penny. As a proud foot soldier of Open Source, I'll clarify that point. I'm the author of three GNU GPL licensed apps: UMENU, Htmlslides and VimOutliner. I never made a penny selling them. Nobody ever offered me a job, contract, speaking opportunity or board of directors position based on my Open Source authorship. And yet I'm sure I'll author more Open Source apps. Here's why...
I needed these programs, and couldn't find or buy satisfactory equivalents. My last 10 or so presentations have been given with Htmlslides. VimOutliner is my most crucial app. All my time and resource planning is done with VimOutliner. Every day more of my business is conducted with VimOutliner. The entire structure of my new book was created with VimOutliner. Almost 1000 headings! I've made a lot of money with VimOutliner -- much more than I could have made trying to sell it. So I put a GNU-GPL license on it to preserve its availability forever, and now you too can profit by using it.
But what if there are no more programmers? What if the lack of software sales potential ends the need for programmers?
Programmers will always be needed to adapt software -- either proprietary or Open Source, to businesses. And as long as the supply of programmers is assured, so is the supply of Open Source.
Open Source is here to stay, and is getting more abundant every day. The future belongs to those who use it.
You don't make money trying to sell an abundant resource. You
make money using it.
Any article submitted to Troubleshooting Professional Magazine must be licensed with the Open Publication License, which you can view at http://opencontent.org/openpub/. At your option you may elect the option to prohibit substantive modifications. However, in order to publish your article in Troubleshooting Professional Magazine, you must decline the option to prohibit commercial use, because Troubleshooting Professional Magazine is a commercial publication.
Obviously, you must be the copyright holder and must be legally able to so license the article. We do not currently pay for articles.
Troubleshooters.Com reserves the right to edit any submission for clarity or brevity, within the scope of the Open Publication License. If you elect to prohibit substantive modifications, we may elect to place editors notes outside of your material, or reject the submission, or send it back for modification. Any published article will include a two sentence description of the author, a hypertext link to his or her email, and a phone number if desired. Upon request, we will include a hypertext link, at the end of the magazine issue, to the author's website, providing that website meets the Troubleshooters.Com criteria for links and that the author's website first links to Troubleshooters.Com. Authors: please understand we can't place hyperlinks inside articles. If we did, only the first article would be read, and we can't place every article first.
Submissions should be emailed to Steve Litt's email address, with subject line Article Submission. The first paragraph of your message should read as follows (unless other arrangements are previously made in writing):
Copyright (c) 2001 by <your name>. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, version Draft v1.0, 8 June 1999 (Available at http://www.troubleshooters.com/openpub04.txt/ (wordwrapped for readability at http://www.troubleshooters.com/openpub04_wrapped.txt). The latest version is presently available at http://www.opencontent.org/openpub/).
Open Publication License Option A [ is | is not] elected, so this document [may | may not] be modified. Option B is not elected, so this material may be published for commercial purposes.
After that paragraph, write the title, text of the article, and a two sentence description of the author.