Slashdot Mirror

The original concept of free, Open Source software was that of programmers writing software they wanted for themselves and sharing it with their peers like poets writing work that only other poets would ever read. Now Open Source and free software are getting major attention. There is suddenly an adoring public out there beyond the footlights. And the presence of this audience is changing the entire Open Source "movement." (more below)

Coming Out of the Programming Closet
I remember the first time I suggested an improvement to a piece of free, Open Source software. The testy response I got was, "Learn to program and do it yourself." This attitude was similar to that displayed by what I call "academic writers," whose fiction and poetry is so obscure that no one reads it except other academics.

But in the last few years, I've noticed a slow change in attitude among the Open Source and free software developers I know personally. More and more of them seem to be thinking in terms of writing software that is useful to others, not just what they want for themselves.

There is nothing wrong with this. Artists need audiences. So do techies. Sure, it's nice to write a "deep" piece of fiction that only top-rung English professors will appreciate, but it's also nice to write something that a whole bunch of people will read and understand, and perhaps even write you a letter or e-mail now and then that says "Thanks. Nice work."

Playing an instrument, reading a poem or performing a dramatic work on a stage in a theater full of adoring fans is certainly more gratifying than doing it alone, in private, or strictly in front of other musicians or actors.

Let's not veer off into the skeptical-but-valid "Is programming really an art?" question. Let's just say that it is a skill that takes both talent and practice, and that not everyone can do it well. In this way, if no other, it is similar to acting, singing, and other performing arts. And there is no reason talented programmers shouldn't get the same level of recognition as talented actors and musicians.

Will Success Spoil Rock Codeson?
It depends on what you call "success." By monetary standards, Bill Gates is more "successful" than Alan Cox a million times over. But I know who I'd rather invite over for a beer, and I'm sorry, Bill, it's not you. I can also think of dozens of actors and musicians whose work I think is wonderful, but who have never been (and may never be) nearly as famous or rich as others for whom I have no respect.

To go back to the theatrical metaphor, there are plenty of marvelous shows that run for months in off-Broadway and off-off-Broadway theaters without taking in one percent of what a big-time musical like Cats can earn on a single weekend night. But the small theatrical productions often have better acting than what you see in the "major" shows. The music is often more interesting. Scripts in low-budget shows are often far superior to the blanded-down words used in productions with millions of dollars invested in them, that have been tested and revised in so many out-of-town tryouts that somuch life has been squeezed out of them that all they have to offer is glitz and glitter with little or no underlying value. The soul of theater, if you will, is in people working out on the edge, going beyond the norm, thinking with their hearts instead of reading market research studies and holding "focus group" sessions with audience members.

There is beauty in putting your heart into a creation, and there is beauty in watching others respond to that creation. Whether that creation is a song or a piece of code hardly matters; the "click" that comes from connecting with an audience can and should be there in either case. Actors generally recognize this, which is why there are dozens of small stage theaters in and around Los Angeles where screen actors perform - almost always unpaid - works that would never make it onto TV or into movie theaters. There is commercial success, and there is satisfaction. The two are not always the same.

Most of the "free software" writers I know make their livings writing commercial software or from some sort of programming-related consulting. But, like auto mechanics who build race cars on weekends for fun, when they go home they work on projects of their own choosing.

Mechanics who prove their creds on the racetrack always have their pick of the best "shop" jobs. Actors who get good reviews in small stage productions tend to get steady work in movies and TV. And a programmer who has gained recognition by doing excellent free software development is likely to have his or her pick of jobs. In this sense, fame gained by writing free software has direct financial value, and if it is widely-used software, not something that will be used only by a few other programmers, that value is increased substantially.

Building a Portfolio
When an actor, musician or writer goes looking for a job, he or she is expected to show potential employers or freelance clients samples of previous performed or published work. If that work has been performed or published to great public acclaim, so much the better.

Right now, programmers, like auto mechanics, are in short supply. A resume that says you have worked for So-and-So inc. for X amount of time, and have experience with Y language (or for the mechanic, on Z make of car) will get you in the door and will probably land you a decent job. And if you're satisfied with that, fine. The world needs ordinary grunt-work coders and ordinary "do brake jobs all day" mechanics. But in either field, the plum jobs go to those who can point to extraordinary individual accomplishments.

For the mechanic, the best proof of accomplishment has traditionally been the winning race car. For the programmer, the stellar proof of personal accomplishment is a popular piece of free software.

Look at Miguel de Icaza. A few years ago he was an obscure listing in the Linux Source, best known for his work on Midnight Commander. Today he's running a well-financed startup, and I'm sure he didn't have to look very hard for backers. But his work on Midnight Commander and other free software projects, even before Gnome made him famous, was more than enough to guarantee him not only an excellent living as a programmer, but complete freedom from "industrial-style" code writing for the rest of his life.

I suspect we'll see a lot more energetic, imaginative young programmers following in Miguel's footsteps instead of going into the highest-paying jobs they can find as soon as they can find them. Will some of them be doing this so that they can reap great financial rewards later? Of course! Not everyone can be a saint like Richard M. Stallman; Jean-loup Gailly, previously best-known as the principal author/maintainer of gzip, is now CTO of MandrakeSoft. And I'm sure there are countless others whose free software fame is getting them not only kudos but excellent salaries. And there's nothing wrong with that.

Passing Batons
We can sit around and cry about how free software developers are being "corrupted" by fame and money, but it's pointless. For one thing, just as the mechanic who gets promoted to shop foreman can still build race cars on his own time, and successful movie actresses often do unpaid stage acting on the side, there's no reason for people who use free software work as a springboard to fortune to give up their prior love. And many don't. They keep on doing what they always did, after work, on their own time. (And a few exceptionally lucky ones actually get to develop free software all day long for pay, but they're still a rare breed.)

But today's free software developers are not the be-all and end-all of the idea. Free software is starting to produce enough success stories that even if all of today's luminaries end up working for Microsoft, Adobe, and other big proprietary development houses within the next decade, plenty of new ones will come along, as hungry for applause as any group of talented young actors and singers.

And as more free software developers realize that by treating users as adoring fans - not as annoyances - they can earn even more applause, there will be more users. And more applause. And more developers. And if this upward spiral can become self-perpetuating, in a few years movie stars may be asking free software developers for their autographs instead of the other way around.

The original concept of free, Open Source software was that of programmers writing software they wanted for themselves and sharing it with their peers like poets writing work that only other poets would ever read. Now Open Source and free software are getting major attention. There is suddenly an adoring public out there beyond the footlights. And the presence of this audience is changing the entire Open Source "movement." (more below)

Coming Out of the Programming Closet
I remember the first time I suggested an improvement to a piece of free, Open Source software. The testy response I got was, "Learn to program and do it yourself." This attitude was similar to that displayed by what I call "academic writers," whose fiction and poetry is so obscure that no one reads it except other academics.

But in the last few years, I've noticed a slow change in attitude among the Open Source and free software developers I know personally. More and more of them seem to be thinking in terms of writing software that is useful to others, not just what they want for themselves.

There is nothing wrong with this. Artists need audiences. So do techies. Sure, it's nice to write a "deep" piece of fiction that only top-rung English professors will appreciate, but it's also nice to write something that a whole bunch of people will read and understand, and perhaps even write you a letter or e-mail now and then that says "Thanks. Nice work."

Playing an instrument, reading a poem or performing a dramatic work on a stage in a theater full of adoring fans is certainly more gratifying than doing it alone, in private, or strictly in front of other musicians or actors.

Let's not veer off into the skeptical-but-valid "Is programming really an art?" question. Let's just say that it is a skill that takes both talent and practice, and that not everyone can do it well. In this way, if no other, it is similar to acting, singing, and other performing arts. And there is no reason talented programmers shouldn't get the same level of recognition as talented actors and musicians.

Will Success Spoil Rock Codeson?
It depends on what you call "success." By monetary standards, Bill Gates is more "successful" than Alan Cox a million times over. But I know who I'd rather invite over for a beer, and I'm sorry, Bill, it's not you. I can also think of dozens of actors and musicians whose work I think is wonderful, but who have never been (and may never be) nearly as famous or rich as others for whom I have no respect.

To go back to the theatrical metaphor, there are plenty of marvelous shows that run for months in off-Broadway and off-off-Broadway theaters without taking in one percent of what a big-time musical like Cats can earn on a single weekend night. But the small theatrical productions often have better acting than what you see in the "major" shows. The music is often more interesting. Scripts in low-budget shows are often far superior to the blanded-down words used in productions with millions of dollars invested in them, that have been tested and revised in so many out-of-town tryouts that somuch life has been squeezed out of them that all they have to offer is glitz and glitter with little or no underlying value. The soul of theater, if you will, is in people working out on the edge, going beyond the norm, thinking with their hearts instead of reading market research studies and holding "focus group" sessions with audience members.

There is beauty in putting your heart into a creation, and there is beauty in watching others respond to that creation. Whether that creation is a song or a piece of code hardly matters; the "click" that comes from connecting with an audience can and should be there in either case. Actors generally recognize this, which is why there are dozens of small stage theaters in and around Los Angeles where screen actors perform - almost always unpaid - works that would never make it onto TV or into movie theaters. There is commercial success, and there is satisfaction. The two are not always the same.

Most of the "free software" writers I know make their livings writing commercial software or from some sort of programming-related consulting. But, like auto mechanics who build race cars on weekends for fun, when they go home they work on projects of their own choosing.

Mechanics who prove their creds on the racetrack always have their pick of the best "shop" jobs. Actors who get good reviews in small stage productions tend to get steady work in movies and TV. And a programmer who has gained recognition by doing excellent free software development is likely to have his or her pick of jobs. In this sense, fame gained by writing free software has direct financial value, and if it is widely-used software, not something that will be used only by a few other programmers, that value is increased substantially.

Building a Portfolio
When an actor, musician or writer goes looking for a job, he or she is expected to show potential employers or freelance clients samples of previous performed or published work. If that work has been performed or published to great public acclaim, so much the better.

Right now, programmers, like auto mechanics, are in short supply. A resume that says you have worked for So-and-So inc. for X amount of time, and have experience with Y language (or for the mechanic, on Z make of car) will get you in the door and will probably land you a decent job. And if you're satisfied with that, fine. The world needs ordinary grunt-work coders and ordinary "do brake jobs all day" mechanics. But in either field, the plum jobs go to those who can point to extraordinary individual accomplishments.

For the mechanic, the best proof of accomplishment has traditionally been the winning race car. For the programmer, the stellar proof of personal accomplishment is a popular piece of free software.

Look at Miguel de Icaza. A few years ago he was an obscure listing in the Linux Source, best known for his work on Midnight Commander. Today he's running a well-financed startup, and I'm sure he didn't have to look very hard for backers. But his work on Midnight Commander and other free software projects, even before Gnome made him famous, was more than enough to guarantee him not only an excellent living as a programmer, but complete freedom from "industrial-style" code writing for the rest of his life.

I suspect we'll see a lot more energetic, imaginative young programmers following in Miguel's footsteps instead of going into the highest-paying jobs they can find as soon as they can find them. Will some of them be doing this so that they can reap great financial rewards later? Of course! Not everyone can be a saint like Richard M. Stallman; Jean-loup Gailly, previously best-known as the principal author/maintainer of gzip, is now CTO of MandrakeSoft. And I'm sure there are countless others whose free software fame is getting them not only kudos but excellent salaries. And there's nothing wrong with that.

Passing Batons
We can sit around and cry about how free software developers are being "corrupted" by fame and money, but it's pointless. For one thing, just as the mechanic who gets promoted to shop foreman can still build race cars on his own time, and successful movie actresses often do unpaid stage acting on the side, there's no reason for people who use free software work as a springboard to fortune to give up their prior love. And many don't. They keep on doing what they always did, after work, on their own time. (And a few exceptionally lucky ones actually get to develop free software all day long for pay, but they're still a rare breed.)

But today's free software developers are not the be-all and end-all of the idea. Free software is starting to produce enough success stories that even if all of today's luminaries end up working for Microsoft, Adobe, and other big proprietary development houses within the next decade, plenty of new ones will come along, as hungry for applause as any group of talented young actors and singers.

And as more free software developers realize that by treating users as adoring fans - not as annoyances - they can earn even more applause, there will be more users. And more applause. And more developers. And if this upward spiral can become self-perpetuating, in a few years movie stars may be asking free software developers for their autographs instead of the other way around.

Chris Beard of The Puffin Group wrote in to say that the birds are partying again. Throughout the week, anyone at ALS will have the opportunity to hack on, or talk to someone hacking on the PA-RISC port of Linux (which is rumoured to boot sash now). The Puffins also sponsored two BOFs today - anyone have a report to give?

Chris Beard of The Puffin Group wrote in to say that the birds are partying again. Throughout the week, anyone at ALS will have the opportunity to hack on, or talk to someone hacking on the PA-RISC port of Linux (which is rumoured to boot sash now). The Puffins also sponsored two BOFs today - anyone have a report to give?

Matt Welsh has written in to talk a bit about the future of a project that he is very familiar with. The LDP ^[?] has been essential to help newbies (and even experts) learn what they need on their quest to become gurus. Hit the link below to read what Matt has to say about where the project ought to head. The following was written by Matt Welsh , co founder of the LDP Thoughts on the Linux Documentation Project In the last few months, the Linux Documentation Project has been in a bit of a rough spot, and it seems that things have not been moving along as smoothly as they were for the last 5 years. I have seen the latest "LDP Proposal" on the Open Source Writer's Group website, and I have a few thoughts on the current state of the LDP and what should be done to fix it.

As the original co-founder and coordinator of the LDP, I did a lot of work to make the project a popular source of Linux documentation. I started the LDP website, moderated the newsgroups, ran the mailing lists, acted as the liason between LDP writers and CD-ROM vendors and paper publishers. So I'd like to share my thoughts about what the LDP needs to get back on track.

In a nutshell, my approach would be minimalistic. I have always found that when organizing a group of volunteers on the Internet, doing less is always better than doing more.

Here's what I mean: The LDP is primarily a vehicle for Linux enthusiasts and developers to share their knowledge about the system with other Linux users. People are motivated to contribute to the LDP because they know that by having their docs on the LDP website, and on many CD-ROM disrtibutions, and even in printed books, that many Linux users are likely to read what they have written. This is much better than burying the docs on a website somewhere and relying on a search engine. The LDP is the de facto standard place for people to go to find out about Linux -- first.

As such, it is *vital* that it is as easy as possible for people to contribute to the LDP. Participation in complex standards processes, voting organizations, or high-traffic mailing lists should never be a requirement. Likewise, the tools used to write LDP docs should be easy to use, widely-available, free, and well-supported.

Ideally, we should allow people to write LDP docs in any format they wish -- but I have found that this makes it quite difficult for the LDP maintainers to publish the docs in a common format. My compromise was to always allow people to contribute docs in plain ASCII, but the preferred tool was Linuxdoc-SGML (now SGML-Tools). SGML-Tools is very easy to use and automatically generates HTML, ASCII, TeX, DVI, PostScript, and texinfo from a single source file. Also, it works with any text editor. Any system which imposes additional responsibilities on authors makes the barrier of entry too high, and people will be less likely to contribute.

Another important aspect of the LDP is that it is vendor-neutral and run by volunteers. For the LDP to be a mouthpiece of a large (or small) Linux distributor or other company would defeat its purpose. I am not suggesting that for The Puffin Group to "take over" the management of the LDP would be a bad thing -- but it is important to make it clear that the LDP is open to contribution by anyone, and is not a closed, privately-run organization motivated by corporate profit concerns. Otherwise, the LDP loses its identity as an open organization which exists to serve the Linux community as a whole.

My strong conviction is that the LDP exists for only two purposes: First, to provide widely-distributed, online publication of Linux documentation (through the website, USENET, and other means). This frees authors from having to concern themselves with making docs available: they simply send the materials to the LDP maintainer and the rest is taken care of. The second purpose is to act as liason between authors and organizations which wish to publish LDP materials on CD-ROM or in print. It is important that LDP authors are represented to publishers in this way -- publishers rarely want to deal with authors individually, but would rather deal with the LDP "as a whole".

There are some pitfalls which I think the LDP needs to be careful of when moving forward:

1. Too much bureaucracy. Turning the LDP into a complex organization with offices, roles, voting procedures, and standards does nothing to further the goal of Linux documentation; all it really does is feed the egoes of the people involved. No other successful Linux project requires this level of bueaucratic organization. Keeping things informal makes it easier to move forward and to be flexible in light of change. I have seen too many Linux projects die (or take too long to get any useful work done) because of political infighting based on organizational procedures rather than meaningful technical details.
2. Changing tools. Unless there is a compelling, immediate, and inevitable reason why some new documentation format is required, don't waste your time trying to convert all of the docs and educate all of the authors about how to use the new tools. Adopting Linuxdoc-SGML was hard enough in the beginning; it only happened because it was so easy to use and we provided a lot of examples and documentation for the tools themselves. I haven't seen any compelling reasons why DocBook (or any other tool) will make Linux documentation any better. At the very least, accept LDP docs in *both* Linuxdoc-SGML and DocBook indefinitely. Forcing authors to adopt a new tool is the best way to scare people off. The LDP isn't about tools; it's about documentation. Don't let the tools weenies take over.
3. Too much -- or too little -- leadership. Leadership in the LDP is really an oxymoron, because the group doesn't need any real leadership. All it needs is someone to work hard maintaining the documentation archives, running mailing lists, posting to USENET, and working with the various paper and electronic publishers who want to redistribute LDP materials. What it also needs is someone who is communicative, open-minded, and clear-headed enough to direct the group's energy towards productive means, rather than endless political discussions. What the LDP doesn't mean is a group of people to overlay a complex organizational structure over something which is essentially a loose-knit collection of enthusiastic writers.
4. Using the wrong copyright. My feeling is that the LDP should adopt a *class* a copyright licenses which it will accept for LDP docs, similar to the Open Source Definition. This will allow individuals to select their own preferred copyright license for LDP materials, within a certain range of allowable licenses. Forcing authors to adopt a single license simply means you will have fewer contributors. Some people distrust the GPL, others distrust the BSD license, and still others prefer to craft their own. You need to be flexible enough to accept a range of copyrights from authors.
5. Too much planning. Setting out a roadmap for a collection of documents that need to be written is the best way to ensure that nobody will ever write them. Writing docs gets done in bits and spurts, and can look like a pretty big job if someone draws up a big outline for a mega-tome which the LDP plans to work on. The HOWTO project was so successful because people could write as much -- or as little -- as they wanted to on a topic of particular interest to them. So what if it's not organized into a coherent whole? With the aid of indices and search engines, people will eventually find what they're looking for. Also remember that ownership of LDP documents is a lease: if someone fails to maintain or update their document over time, it's perfectly acceptable for someone else to revise it or rewrite it altogether. This happened several times with documents that I originally authored.

In short, I think that the only thing the LDP needs to do to get on track is to retain the essential structure it has had for the last five years. Making things any more complicated will only raise the barrier of entry to new authors, which will eventually cause the project to die out. The LDP worked so well because it took almost no effort for someone to contribute: all they had to do was e-mail me the source for a new HOWTO. As soon as you become embroiled in discussions about new tools and bureaucracies, the LDP stops getting useful work done and starts becoming "yet another overburdened Linux project". My advice is to keep it simple.

I appreciate any comments.
Thanks,
Matt Welsh, mdw@cs.berkeley.edu

Phexro writes "Looks like Nick Petreley, IDG and the LinuxWorld gang have a neat idea- Open Books. They are soliciting the Linux community to help write "The Essential Linux", which will be written and edited completely(?) by the members of the Linux community. The finished work will be distributed under the terms of the IDG Books Open Content License." I'll probably volunteer; I'm already in the Open Source Writers Group. But will enough others participate to make it a viable project? (More below)

The reason I wonder if this project (which I think is an excellent idea) will draw enough support is that it's facing stiff competition from commercial publishers. The market for Linux books is so hot right now that one New York literary agent I know, Lisa Swayne, is literally begging for Linux authors.

While much Linux software is free, books about it cost plenty. An awful lot of people, including me, have noticed this and are not happy about it. Writing is not that much different from coding. In many ways. the two tasks are different applications of the same talents, and the way writers and coders work is quite similar, especially the fact that people who are good (or want to get good) at either task often become so obsessed with their work that they give up almost everything else in their lives. Given this similarity, why should people who write about free software almost invariably get paid, while people who write free software are expected to "contribute to the community" without getting any money in return?

Personally, I believe it is the duty of any writer or editor who uses free software to donate his or her skills to the community, just as programmers who use free software often contribute bugfixes and patches even if they aren't heavily involved in kernel or applications development. We each can and should contribute in our own way.

But now Linux is going big-time, and publishers move in packs just as surely as Wall Street investors, so suddenly there's competition for anyone who can write competently about Linux. I believe this is going to lead to a lot of bad books, just as the explosion of science fiction's popularity in the 1970s led to the publication of many SF novels that never should have been printed.

I believe Open Source books have the potential to be better and more useful manuals than those written under commercial pressure. Editing is the writer's equivalent of debugging. Just as good programmers often spend more time debugging than actually writing code, good writers often spend more time editing their work than typing their first drafts.

If you are a programmer who can write, or a writer who understands programming, I urge you to donate at least a little of your precious time to either of the two Open Source writing projects mentioned above, or to one of the many other worthwhile ones that have sprung up elsewhere.

Sure, there's lots of pressure to spend every waking moment making money coding or writing, but doing the same work without deadline pressure, for love instead of money, at least a few hours every week, will not only make you feel better about yourself, but may also help you improve your skills in ways you cannot when you're cranking out copy or code against a commercial deadline.

Note: this story was posted briefly earlier, then pulled when we discovered that LinuxWorld's servers weren't responding. Now, at 1:13 EDT, LinuxWorld is back up, so the links all work. - ed

dria writes "The Puffin Group yesterday announced that it will be fully sponsoring the Open Source Writers Group, a growing organization of volunteer writers, editors, proofreaders, and translators who donate their time toward non-commercial open-source projects. The Puffin Group will provide the Open Source Writers Group with a combination of technical resources and financial compensation in order to ensure its continued existence and growth. "

dria writes "The Puffin Group yesterday announced that it will be fully sponsoring the Open Source Writers Group, a growing organization of volunteer writers, editors, proofreaders, and translators who donate their time toward non-commercial open-source projects. The Puffin Group will provide the Open Source Writers Group with a combination of technical resources and financial compensation in order to ensure its continued existence and growth. "

dria writes "The Puffin Group yesterday announced that it will be fully sponsoring the Open Source Writers Group, a growing organization of volunteer writers, editors, proofreaders, and translators who donate their time toward non-commercial open-source projects. The Puffin Group will provide the Open Source Writers Group with a combination of technical resources and financial compensation in order to ensure its continued existence and growth. "