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.
[ 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)
|
CONTENTS
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:
- I became satisfied with VimOutliner just the way it was.
- Other priorities increasingly sapped all time I would have used for
VimOutliner.
- 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.
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.
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.
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 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:
THANKS!
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.
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...
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...
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:
- It was trivial to do
- It was easy for a human to differentiate body text from a series of
long headlines
- 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...
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:
- The project dies
- The project forks
- 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)
To: leaplist@lists.leap-cf.org
Reply to: leaplist@lists.leap-cf.org
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.
SteveT
_______________________________________________
LeapList mailing list
LeapList@lists.leap-cf.org
http://www.matrixlist.com/mailman/listinfo/leaplist
|
To grow, caterpillars become butterflies, snakes shed their skins. Sometimes
growth means project originators hand off to a competant successor.
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:
- Executable lines
- Hoisting
- Spellchecking
- Checkboxes
- Modeless editing (intuitive, like MS Notepad)
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.
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:
- What is the programmer's incentive to write it?
- How does one profit from free software?
- Is it here to stay?
- How do unpaid programmers organize themselves to produce free software?
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 http://www.fsf.org/philosophy/free-sw.html,
and the Open Source definition is available at http://www.opensource.org/docs/definition.php.
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:
- The freedom to run the program, for any purpose.
- The freedom to study how the program works, and adapt it to your needs.
- The freedom to redistribute copies.
- The freedom to improve the program, and release your improvements to
the public.
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 http://opencontent.org/openpub/.
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 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.
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.
Trademarks
All trademarks are the property of their respective owners. Troubleshooters.Com(R)
is a registered trademark of Steve Litt.
URLs Mentioned in this Issue
- MISC URLs
- Free Software/Open Source URL's
_