Troubleshooters.Com Presents

Linux Productivity Magazine

Volume 2 Issue 10, October 2003

A Free Software Project Moves On

Copyright (C) 2003 by Steve Litt. All rights reserved. Materials from guest authors copyrighted by them and licensed for perpetual use to Linux Productivity Magazine. All rights reserved to the copyright holder, except for items specifically marked otherwise (certain free software source code, GNU/GPL, etc.). All material herein provided "As-Is". User assumes all risk and responsibility for any outcome.

See also Troubleshooting Techniques of the Successful Technologist
and Rapid Learning: Secret Weapon of the Successful Technologist
by Steve Litt

[ Troubleshooters.Com | Back Issues |Troubleshooting Professional Magazine ]

When you lose interest in a program, your last duty is to hand it off to a competent successor. -- Eric Raymond (Chapter 2 of The Cathedral & the Bazaar)


Editor's Desk

By Steve Litt
When you lose interest in a program, your last duty is to hand it off to a competent successor.

Eric Raymond penned those words -- I lived them. During the last week of September, 2003, I handed off the VimOutliner project to Noel Henson, who had been doing most of our development for over a year. In doing so, I learned yet more lessons about free software.

First, let's get this out of the way -- I didn't lose interest in VimOutliner. I use it every single day, hours per day. I love it. It's a huge part of my work and my productivity. What happened is three things:
  1. I became satisfied with VimOutliner just the way it was.
  2. Other priorities increasingly sapped all time I would have used for VimOutliner.
  3. Noel Henson and several other VimOutliner people were better Vim programmers than me.
Increasingly, awaiting my approval to put in a new feature became the project's bottleneck. The time had come to go -- I handed it off, and in doing so, graduated VimOutliner from a cult of personality to a long term, functioning project.

This Linux Productivity Magazine is about free software, Open Source, whatever you want to call it. It discusses the genesis of a project starting as the work of a single person, the expansion and transformation of the project as others join it, and, as often happens, the project's outgrowing its originator. If you're like me, considering these things will help you better understand this phenomenon known as free software or Open Source.

Steve Litt is the author of Samba Unleashed.   Steve can be reached at Steve Litt's email address.

Help Publicize Linux Productivity Magazine

By Steve Litt
Loyal readers, I need your help.

For months I've publicized Linux Productivity Magazine, expanding it from a new magazine to a mainstay read by thousands. There's a limit to what I can do alone, but if you take one minute to help, the possibilities are boundless.

If you like this magazine, please report it to one of the Linux magazines. Tell them the URL, why you like it, and ask them to link to it.

I report it to them, but they don't take it very seriously when an author blows his own horn. When a hundred readers report the magazine, they'll sit up and take notice.

Reporting is simple enough. Just click on one of these links, and report the magazine. It will take less than 5 minutes.

News Mag
Submission URL or Email address
Just fill in the short form.
Just fill in the short form.
Linux Weekly News
Just tell them the URL, why you like it.
Just tell them the URL, why you like it.
Just fill in the short form.
Newsfactor Network
Just tell them the URL, why you like it.
The Linux Knowledge Portal
Just tell them the URL, why you like it.
OS News
Just tell them the URL, why you like it.
Only for LPM issues involving the Linux desktop, not for programming or server issues.

If you really like this magazine, please take 5 minutes to help bring it to a wider audience. Submit it to one of the preceding sites.
Steve Litt is the author of Samba Unleashed.   Steve can be reached at Steve Litt's email address.

Genesis of an Itch

By Steve Litt
It is said that every free software project begins with a programmer "scratching an itch". In other words, he needs to do a task, or do the task better, and no existing software accommodates that end. So he writes his own. But what creates the itch in the first place?

I submit to you that we're all a product of the sum of a life time of habits. We learn methodologies that maximize our success, and we use those methodologies. So it was for me.

Miss Krenwinkel

Miss Krenwinkel was ancient. She was my 7th grade teacher, and had been my mother's teacher before me. My mother described Miss Krenwinkel as "very old" when my mom had her, so you can imagine her age by the time she got to me.
She wasn't one of those cute "nice old ladies". Miss Krenwinkle was huge, with the shoulders of a linebacker. She hobbled heavily on a thick wooden cane, and you'd always look twice at that cane before misbehaving. A past cataract operation left her without lenses in her eyes, enabling her to see ultraviolet light. And you always suspected it allowed her to see around corners, because she always knew when you'd been bad behind her back.

Miss Krenwinkel was a former penmanship teacher, and as you might suspect, she prioritized form and style over content. Reading this magazine, you can imagine the conflicts that set up between her and me. It was a year of lousy grades and corrected papers glowing with red ink. I remember only one thing that Miss Krenwinkel taught me. But it was a doozey...

Miss Krenwinkel
Miss Krenwinkel

Miss Krenwinkel insisted we all submit outlines several days before submitting our papers. No writing the paper first and then making an as-built outline to match -- she insisted we use the outlines as design tools. Didn't the old battleaxe know we had more than enough work just writing the paper? Grrrrrr!

But even in 7th grade, I had to admit that once the outline was complete, writing the paper was easier.

Subsequent teachers didn't insist on pre-paper outlines, so I went back to stream of consciousness papers except for those papers so huge that stream of consciousness would have been suicide. But I filed away Miss Krenwinkel's mandate for later.

Slacker Daze

From college graduation at 23 to my becoming a programmer at 32, I was an anti-intellectual. If I read at all, it was fiction with the occasional inane popular press self-help book. Jobs were consistently beneath my level of expertise. Life was rarely challenging. But when things got challenging, I remembered the lessons of Miss Krenwinkel, and outlined.

At 30 I moved from Chicago to Los Angeles, planned the move as a project, with an outline. The move went off without a hitch.

I knew that when the going got tough, the tough write an outline. But I hadn't yet gotten it though my thick skull that outlines help every day -- not just in emergencies.

Whomping Out the Code

At 32 I took a microprocessor course, and while my classmates struggled to add a memory location to an accumulator, I soldered an audio jack to one of its LEDs and programmed it to play music. Trouble was, when my program exceeded more than about 50 machine instructions (it was programmed in hexadecimal), bugs crept in and it crashed. Looking for a more reliable way to program, I remembered my programmer friend Paul Watkins mentioning that the new thing was "modular programming". Looking it up in my microprocessor course textbook, I found that modular programming was simply substituting subroutine calls and return statements for goto statements, thereby creating independent subroutines that can be further broken down into more subroutines. I tried modular programming, and 3 days later I'd programmed a computer guitar with tuneable tempo and slide guitar action. I was a believer!

In subsequent Cobol and Pascal classes, my teachers emphasized modular programming and its design methodology, functional decomposition. Most of my classmates ignored it, but after my recent harrowing experience with crashing gotos, I followed their instructions to a T. Consistent use of functional decomposition was my ticket into the job market and a wonderful career.

Some years later I noticed that functional decomposition could be done with an outline. After that, outlining became my primary tool for design and planning in all my life's activities. Lucky thing, because a few years later I started writing books. When I discovered computer assisted outlining, I was in heaven.

Miss Krenwinkel, you seemed 200 years old when I was in 7th grade, but I'm sure you're still alive and teaching. You're too ornary to quit. And I know that, with your ultraviolet enabled eyes, you see me writing this no-style, all content magazine. So before you pick up that red pencil you're so fond of, I have just one word for you Miss Krenwinkel:

Steve Litt is the author of the Universal Troubleshooting Process courseware.   Steve can be reached atSteve Litt's email address.

The Itch

By Steve Litt
In the late 80's I discovered the joys of outlining with WordPerfect 4.2. I quickly adopted WordPerfect for functional decomposition, and sped my design process. You couldn't call WordPerfect an outliner -- no collapse/expand, no interoutline linking, no way of incorporating non-text data. But for a guy accustomed to outlining with pencil and paper, it was heaven.

I switched to the Grandview outliner in the early 1990's. No shortage of features here. Demote/promote, collapse/expand, hoist/dehoist, body text, interoutline linking, and cloning. The keyboard driven interface was good, but due to various slash key combinations it was a little cumbersome. Nevertheless, the interoutline linking allowed a single knowledge repository anchored off a master outline, so that by 1995 much of my knowledge was stored in my Grandview outline tree. Had I been able to use executable headlines, linking, embedding, etc. with Grandview, I could have incorporated *all* my knowledge into Grandview. But either it didn't have that feature, or I never found it. Besides, Symantic abandoned Grandview in the mid 1990's.

Around 1996 I found what, in many respects, was the best outliner ever -- Microsoft Word. MS Word was a keyboarder's dream -- collapse/expand was a simple matter of Tab and Delete. More complex operations, which are much less commonly used, were doable through more complex keyboard commands, or via easy mouse operations. The feature that really set MS Word apart from the hordes of the golden age of outliners (late 80's and early 90's) was that outlining was a view within a wordprocessor. You could outline a book in outline view, fill in text as body text under the outlines, flip a switch, and the headlines became properly formatted book headings. If you wanted to reorganize your book, you could put it back into outline view, move whole sections around, promote and demote as necessary, flip back to book view, and your book would be reorganized. It was an author's dream. I figured I'd use MS Word forever.

That's not to say MS Word was perfect. Printing the outlines as outlines was difficult. MS Word object embedding and linking was iffy. Lacking any easy to use interoutline linking, my single tree knowledge tree disintegrated. But that seemed a small price to pay for the greatest possible book design tool. I imagined I'd use MS Word forever. But that was not to be.

In 1998 I discovered Linux, in 1999 I vowed to switch over to Linux, and by the end of 2000 I was ready to make the switch, except for the lack of a few strategic tools.

The most glaring omission in the Linux world was that all outliners that ran on Linux seemed substandard in one way or another. Many were barely alpha, and hadn't been improved in months or years. Others were feature rich and performance poor. Every operation required a mouse. By the time you accomplished an operation, you'd forgotten your train of thought. Some were written as molassis slow Java or Javascript web apps. Back then, no outliner would let you outline at thought speed. This was not acceptable.

It was a persistent and irresistable itch.
Steve Litt is the author of "Troubleshooting Techniques of the Successful Technologist".  Steve can be reached at Steve Litt's email address .

Scratching the Itch

By Steve Litt
In March 2001 I switched over to Linux, planning to do my outlining in MS Word and then export to my Linux box. Not optimal, but workable until somebody wrote a good Linux outliner. Within a month of my conversion to Linux, Vim expert Dillon Jones posted to LEAP (Linux Enthusiasts and Professionals) mailing list saying Vim6 was out, and it had folding. He also told me the folding feature could be used with outlines.

I began using Vim6 as an outliner, and wrote about it on Troubleshooters.Com (URL in URL's section). I gradually created Vim and perl scripts to make Vim6 into a better outliner. Dillon came through again in May, responding to my asking how to implement interoutline links. Dillon mentioned tagging. I read about tagging in Vim help and on man pages, and created Perl scripts to implement it. Somewhere around that time, someone else emailed me with a method to color highlight different levels.

I now had a set of Vim config files and scripts plus Perl scripts implementing demote/promote, collapse/expand, and interoutline linking. I called the config and script set VimOutliner, and announced it on the LEAP mailing list (announcement URL in URL's section) on June 1, 2001. It was later announced on Freshmeat, the LyX mailing list, and other places.

Throughout late 2001 I used VimOutliner to outline my book, "Troubleshooting Techniques of the Successful Technologist". Then I wrote a script to convert it to a LyX book structure complete with parts, chapters, sections, subsections, etc, and wrote the book. My itch was scratched, and I went on to other things.

But safely off my radar screen, others plotted VimOutliner's greatness...
Steve Litt is the author of the Universal Troubleshooting Process courseware.   Steve can be reached atSteve Litt's email address.

The Itch Proves Contageous

By Steve Litt
If I did one thing right, it was to make the initial VimOutliner simple and practical. The software I released 6/1/2001 did one thing and did it well. For the first time in Linuxdom, an author could dump his mind to an outline without losing his train of thought. No reaching for a mouse or wading through a heavily featured user interface. This attracted users, who then became beta testers and developers. In the words of Eric Raymond:

When you start community-building, what you need to be able to present is a plausible promise. Your program doesn't have to work particularly well. It can be crude, buggy, incomplete and poorly documented. What it must not fail to do is (a) run, and (b) convince potential co-developers that it can be evolved into something really neat in the forseeable future.

Eric Raymond (From The Cathedral and the Bazaar)
If there was anyone out there who needed an outliner, they would use this program. But were there any such people?

There are two kinds of people -- those who use outlines and those who don't. Now here's a paradox. Many of those who don't, do. But they use outlines because someone forces them to, not because they recognize the intrinsic productivity value of creating outlines. Those who truly use outlines use them for most of their design and planning activities, and absolutelycannot get along without them. I'd say that those who use outlines in this way comprise 1% of the population, but we're highly motivated.

In late May, 2001, a guy named Noel Henson emailed me thanks for my initial article on using Vim6 for outlining. I replied that if he liked that, wait til he sees the VimOutliner package I was creating. He asked to be a beta tester. That's how the VimOutliner project got its second member, before the product's initial release (something Eric Raymond says is difficult in his book, The Cathedral and the Bazaar).

By late October 2001 Matej Cepl from the LyX list wrote me about the unintuitive collapse in VimOutliner. My records show I didn't respond. In June 2002 he again asked about the unintuitive collapse, and this time I did respond -- saying I didn't have time right now. A few others seemed to be using it.

October 2002 rolled around. VimOutliner hadn't changed a bit from what was released sixteen months before. On 10/13/2002 Matej emailed me asking the following question:

Is vimoutliner officially dead, or I should keep helding a breath?

Subsequent emails with Matej indicated that after all these months, he was still waiting for a collapse/expand that would collapse ON the collapsed headline, not BELOW it. Trouble was, I had no idea how to do that.

Coincidentally, five days later Noel Henson emailed to congratulate me on the September 2002 Linux Productivity Magazine, which discussed IceWM. Remembering the VimOutliner problem I couldn't solve, I casually asked how to make the collapse occur on the collapsed headline.

Noel quickly came back with a substantially changed outliner.vim file which implemented collapse/expand correctly, though it had some bugs. After a few days of back and forth with Noel's new outliner.vim, we started sending the messages to Matej also.

Two is company, three is a project. We now had critical mass, complete with suggestions, feedback and testing. LEAP President Phil Barnett arranged for Billy Knight, owner of FiberHosting.Com, to donate a mailing list. Thanks Phil and Billy! Armed with our mailing list, progress was quick and sure. The new VimOutliner 0.2.0, sporting correct collapse/expand, level based color coding, sorting, and several other handy commands, came out on 12/3/2002.

I had sat back, performed no work, and guided the work of others to make VimOutliner a real outliner. Life was good, and life was easy. Or so I thought...
Steve Litt is the author of Rapid Learning: Secret Weapon of the Successful Technologist. He can be reached atSteve Litt's email address.

The End of Unanimity

By Steve Litt
In late 2002, project members hung on to my every word. I was the "genius" who created the first practical Linux enabled outliner. But soon enough, opinions were many. The first difference of opinion was on how to do body text. VimMeister Dillon Jones favored a system of line types designated by the initial character. Matej and Noel favored designating body text by a single space before the text. I favored preceding body text by an initial comment character (in this case a colon), and letting Vim's native comment handling format the body text.

I had reasons for my preference:
  1. It was trivial to do
  2. It was easy for a human to differentiate body text from a series of long headlines
  3. It did not involve the mixing of spaces and tabs, which I consider a debugging nightmare
Matej and Noel felt that preceding colons are ugly, and that a single space would indent the body text, but not so much that it could be confused with subheadlines.

Dillon felt that body text is a subset of the many content types comprising a document: body text, code, warnings, etc. Dillon's idea would have produced a VimOutliner useful for the authoring of an entire book.  Unfortunately, implentation would have been complicated -- nobody knew how to do it, so it never got done.

Figuring I could win the day with a fait accompli, I coded up a quick and dirty body text using an underscore as a Vim syntax comment character.

Not so fast, slick -- everyone else campaigned for their favorite, and Noel quickly coded up a quick and dirty space designated body text :-).

After more discussion we ended up with body text signified either by a colon and a single space, or just a single space, and the ,,b and ,,B commands to switch between the two.

More basic were the continuing requests to remove the ol script. The ol script was a perl script that ran VimOutliner from a single, dedicated VimOutliner tree. Thus, installation of VimOutliner was a simple tree copy and a little configuration. No need for Vim, or any other application, to know anything about VimOutliner. VimOutliner could be removed with a simple rm -rf command. After years of diddling with Windows .dll files and registries, I had promised myself to make VimOutliner self-contained in its own tree, with no shared configuration. I felt so strongly about this that it was one of the principles enumerated in the project charter, written before anyone but me had seen the code. That project charter was like a constitution -- it guided our activities and our priorities.

Now were others not only calling for ways to run VimOutliner without theol command, but they also wanted VimOutliner to be a Vim plugin, even if that meant recognition of VimOutliner data files by filetype. Heresy! Unconstitutional!

And the vast majority on the VimOutliner mailing list supported this unconstitutional change. Well -- that's what constitutional amendments are for. I changed the charter, and Noel changed VimOutliner. I did manage to get the others to agree on a rather strict naming convention for VimOutliner files, so that they would never be confused with other Vim files, and VimOutliner de-installation would be as simple as a wildcard delete.

The result was a huge improvement, eliminating many perl, bash and Vim scripts, resulting in a simpler product. Naming conventions retained some of the system wide modularity. VimOutliner became easier to operate, and more popular.

Then there was the matter of executable lines. Executable lines are just what they sound like -- a headline that, when hit with a certain keystroke command (,,e in this case), executes a bash command. This is important because it allows you to view/edit web pages, images, sound clips and the like from within an outline. In this way your outline tree becomes a true single tree knowledge repository.

Our mailing list couldn't decide on a format for executable lines, so I finally just cobbled something together and placed it on the VimOutliner web page, outside of the main distribution. Some used it, some didn't, some probably use a different syntax. Some day we'll decide on a standard, but for now, everyone who wants executable lines has them.

Why is a Project Like a Child?

A little baby's parents make all decisions for the baby. As the child progresses through elementary school, the the child's peers and his own personality take an increasing role. By high school, the parent hopes to influence major decisions, but doesn't sweat the small stuff when the child disagrees.

When you initiate a project, you're the only developer, and what you say goes. As more developers sign on to the project, they take an increasing role in determining the project's direction. In time, your role in the project is mere facilitation.

So that's why a free software project is like a child. And as we all know, someday every child leaves his parents home...
Steve Litt is the author of the Universal Troubleshooting Process courseware.   Steve can be reached atSteve Litt's email address.

A Free Software Project Moves On

By Steve Litt
By early 2003 VimOutliner was the outliner of my dreams -- collapse/expand, demote/promote, body text, interoutline linking and executable lines. My itch was scratched.

Not so for the others on the list. They made improvements ever more quickly, but it took me an age to get around to testing those improvements. Increasingly I was the project's bottleneck. It was obvious to everyone. They were nice about it, but it was obvious they weren't pleased.

There were three possible outcomes:
  1. The project dies
  2. The project forks
  3. I pass the project off to a competant successor
Noel had been our main developer since October 2002, so he was the obvious choice. I phoned him, asked him about his views on the direction of the project, verified that his direction would lead to a good place, and made my decision.

I emailed the VimOutliner list suggesting that Noel become our maintainer. Agreement was quick and unanimous. I passed it off.

If You Love Something Set It Free

If you're reading this magazine, chances are someday you'll originate a software project and eventually need to hand it off. It's not easy. That's your baby. You raised it from infancy. I didn't share my feelings with the VimOutliner folks, because I didn't want to influence their decision about whether to hand off to Noel. But I emailed LEAPlist with my feelings:

Date: Sun, 28 Sep 2003 17:39:36 -0400
From: Steve Litt <Steve Litt's email address>  (Troubleshooters.Com)
Reply to:

Hi all,

Eric Raymond has written about handing over a project you originated to somebody else. Today I did just that, with VimOutliner, and it's a wierd feeling.

For several months now, I've felt that my being the maintainer of the VimOutliner project was actually slowing the project, and I've contemplated handing over the Maintainer role to Noel Henson, who does most of the VimOutliner development. Within the last week, I realized that I either had to hand over the Maintainer role, or watch VimOutliner's growth be stunted.

I handed it over.

At once, I feel a loss of control over software I use on an hourly basis, pride in a project that has moved beyond a "cult of personality", a prediction that our software will now get A LOT better in a very short period of time, a sadness that I'm no longer THE MAN, and a relief that a responsibility I could no longer handle is off my shoulders.

It's a strange feeling, one that most of you will probably feel it at one time or another.

I guess the VimOutliner mailing list has to vote on it, but the result is a foregone conclusion -- I think it's obvious to everyone that Noel should be the VimOutliner project's maintainer.

So look for great things from VimOutliner in the near future, including automated thought enhancement. And if you're on the VimOutliner list, look for more posts from me now that I'm a suggester instead of a maintainer.


LeapList mailing list

To grow, caterpillars become butterflies, snakes shed their skins. Sometimes growth means project originators hand off to a competant successor.
Steve Litt is the author of Rapid Learning: Secret Weapon of the Successful Technologist. He can be reached atSteve Litt's email address.

VimOutliner's Future

By Steve Litt
You know what happens when you widen a system's bottleneck. The entire system's throughput increases. I was the VimOutliner project's bottleneck -- delaying feature approval. Now I'm no longer the maintainer.

Here is a partial list of features prototyped but never incorporated:
I'd expect these to happen very soon. With a culture more friendly toward change, I'd expect VimOutliner to gain more features, especially in the area of thought enhancement. Another possibility is "user friendly" features including Windows compatibility, menu access to outlining commands (while keeping the keyboard access), and modeless editing.

I predict that within a year VimOutliner will take its place among the greatest outline processors, and maybe surpass them.
Steve Litt is the author of Rapid Learning: Secret Weapon of the Successful Technologist. He can be reached atSteve Litt's email address.

Life After Windows: Understanding Free Software

Life After Windows is a regular Linux Productivity Magazine column, by Steve Litt, bringing you observations and tips subsequent to Troubleshooters.Com's Windows to Linux conversion.
By Steve Litt
No one understands free software. I really believe that. Not Richard Stallman. Not Eric Raymond. Not Linus Torvalds. And CERTAINLY not me.

Stallman, Raymond and Torvalds are the worlds foremost authorities, but free software is so huge, that in my opinion nobody has a grasp on all of it. Also, commodities with zero cost of reproduction are so new that our collective intuitions have trouble with the concept. As time goes on, free software will become more obvious to all of us.

Free software (or Open Source, or whatever you want to call software with the four freedoms), generates many questions:
My journey through the creation and improvement of VimOutliner has shed some light on these questions, and I'd like to share those insights with you.

What is the programmer's incentive to write it?

Certainly most originators write free software to scratch an itch. I needed an outliner, a suitable one didn't exist, so I wrote one. But what about developers who come later?

I once queried everyone on the VimOutliner list about how and how often they used VimOutliner, and most used it on a daily basis. Many had incorporated it into their core work. Interestingly enough, everyone used it differently, used different features, and wanted different additional features.

How does a user get the features he wants? With proprietary software, he begs and pleads, and maybe if enough users beg and plead the vendor will incorporate the feature. Begging and pleading are also an option with free software, but with free software you have an additional option -- create the feature yourself. So once again, scratching an itch is a powerful motivation. Is there another motivation?

You bet there is. Status!

Some guys attain status with an expensive red sports car, or a $2000.00 bicycle, or a speedboat. Geeks attain status by writing code. Trouble is, you can't show off your proprietary code -- it's a trade secret. Imagine purchasing an expensive red sports car, but signing a contract that you'll never show it to anyone. You might as well buy a $9000.00 Hyundai.

Also, many excellent developers don't get paid to write code. Programming has always been a strange marketplace, and with today's recession, outsourcing and offshoring, many excellent programmers turn to free software to keep up their skills and to have fun coding.

There are also social motivations. Let's face it -- being part of a winning team is a wonderful feeling. In the VimOutliner project, we have tons of fun.

In his book, "The Cathedral and the Bazaar", Eric Raymond explores these and many more motivations.

How does one profit from free software?

By using it. It's that simple. You profit from free software by using it. If you need an enhancement to increase that profit, you create that enhancement yourself.

There are other ways to profit. Branding, charging small fees for collections on CD with documentation, give the product and sell the service, and the like. But by far the most reliable way to profit from free software is simply to use it.

Is it here to stay

You bet. As long as programmers continue creating it, free software will be available. And as long as it's available, some individuals will try it. And as people try it, some will become beta testers and developers. And as some software projects surpass their proprietary competitors, they will become ubiquitous.

We already discussed the incentives that will keep programmers coding free software, so free software is here to stay.

How do unpaid programmers organize themselves to produce free software?

Eric Raymond writes extensively on this subject in "The Cathedral and the Bazaar". Let me add what I've discovered.

First, free software is honed by a survival of the fittest selection process very much like biology. There are thousands of free software projects. Most are like my UMENU project -- the originator acting as the sole developer, and the project goes no farther. Some projects are one man bands because the product isn't attractive to others. Some are one man bands because that one man isn't skilled at encouraging others. Some projects fail entirely for those same two reasons.

A select few have the necessary attractiveness and leadership to grow. Linux, Samba, Apache and VimOutliner are examples. These projects offer a needed capability and therefore attract users. If a project has leaders who understand how to motivate (primarily by getting out of the way), it will get many capable developers. Which increases the draw of its needed capability...

So unpaid programmers organize themselves to produce free software by natural selection.

Open Source vs. Free Software

People ask the difference between Open Source and free software. The answer -- mainly philosophy. The licenses and license qualification definitions are similar. The free software definition is available at, and the Open Source definition is available at The definitions are remarkably similar.

What's different is primarily a matter of emphasis. The free software advocates emphasize freedom, as in freedom of speech. For these people, freedom is an end unto itself.

The Open Source advocates emphasize the commercial benefits of software freedom -- the bazaar project style, the "many eyes" quality control system, and the ability to add your own features.

In my opinion, they're both right. Freedom is indeed an end by itself, and in addition that freedom creates tremendous commercial possibilities. Look at VimOutliner. It's GPL license is the "freeest" of all licenses -- you can do anything with it except make it less free to others. Other than that, it's yours almost as if you wrote it. And because of that freedom, others have become involved as developers, so that now the program has been incorporated into the business processes at many companies.

Why I Picked the GPL License for VimOutliner

I'm sometimes asked why I picked the GNU GPL License for the VimOutliner project. The short answer is that GPL is my default license. In the absense of any reason to the contrary, I license my projects GPL. Here's why...

The GPL guarantees the four freedoms:
Beyond that, the GPL has a property called "copyleft", which states that if one modifies and redistributes GPL software, the modified software must also be GPL. This prevents the modifying party from deleting any of the four freedoms from the modified software. I think copyleft is vital to healthy bazaar type development. After all, would you use your time and effort to work on software that could later be made unavailable to you?

Some other licenses require modified versions to be distributed only as patches to the original. This initially might sound like a good idea, because it enables the project's official maintainer to create a "standard version", and prevent "unauthorized" versions, commonly called "forks" because they fork off the original project's source code.

Forks are considered bad. Imagine two competing versions of a project. Which do you choose? Which do you contribute to? Which has the features you want? It's a grim possibility.

But a necessary one. Because when, in the Course of human events, it becomes necessary for the people using software to dissolve the development bands which have connected them with to the project, and to assume among the powers of the earth, the separate and equal station to which the Laws of Nature and of Nature's God entitle them, a decent respect to the opinions of mankind requires that they should declare the causes which impel them to the separation. In other words, if a project's leadership becomes too out of touch, it's the duty of the project's user community to fork the project. It's just like revolution -- grim and bloody, but occasionally necessary.

Without the ability to fork, why would I ever contribute to a project? Ability to fork assures me that I can always use my work, and the work of other contributors. Ability to fork allows me to pass of maintainership of a project, knowing that if 10 years from now a future maintainer screws up, I can take the source code and declare myself maintainer of a fork -- let the best version win.

The GPL license guarantees that all users of the software have the four freedoms for that software, now and in perpetuity.
Steve Litt is the author of the course on the Universal Troubleshooting Process.  He can be reached at Steve Litt's email address.

Letters to the Editor

All letters become the property of the publisher (Steve Litt), and may be edited for clarity or brevity. We especially welcome additions, clarifications, corrections or flames from vendors whose products have been reviewed in this magazine. We reserve the right to not publish letters we deem in bad taste (bad language, obscenity, hate, lewd, violence, etc.).
Submit letters to the editor to Steve Litt's email address, and be sure the subject reads "Letter to the Editor". We regret that we cannot return your letter, so please make a copy of it for future reference.

How to Submit an Article

We anticipate two to five articles per issue, with issues coming out monthly. We look for articles that pertain to the Linux or Open Source. This can be done as an essay, with humor, with a case study, or some other literary device. A Troubleshooting poem would be nice. Submissions may mention a specific product, but must be useful without the purchase of that product. Content must greatly overpower advertising. Submissions should be between 250 and 2000 words long.

Any article submitted to Linux Productivity Magazine must be licensed with the Open Publication License, which you can view at At your option you may elect the option to prohibit substantive modifications. However, in order to publish your article in Linux Productivity Magazine, you must decline the option to prohibit commercial use, because Linux Productivity 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) 2003 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 (wordwrapped for readability at The latest version is presently available at

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.

Why not Draft v1.0, 8 June 1999 OR LATER

The Open Publication License recommends using the word "or later" to describe the version of the license. That is unacceptable for Troubleshooting Professional Magazine because we do not know the provisions of that newer version, so it makes no sense to commit to it. We all hope later versions will be better, but there's always a chance that leadership will change. We cannot take the chance that the disclaimer of warranty will be dropped in a later version. 


All trademarks are the property of their respective owners. Troubleshooters.Com(R) is a registered trademark of Steve Litt.

URLs Mentioned in this Issue