22 Jun 2002 bytesplit   » (Journeyer)

Growing laterally and regressing instructively?

There are two things that I have noticed about the Unix and Linux world out there, unfortunately for me they both are observations that don't often cause other unix and linux users' faces to light up with excitement. First, there are way too many open source projects in relation to the number of people working on them. This is why you see tens upon tens of editors, with only a minute number actually being of real quality. I know quality when I see it, just as any computer user does. What I define as 'quality work' may be totally different than, say for example, what Joe Schmoe thinks 'quality work' means. Since a lot of people have agreed with me on my definition of 'quality work', and because it is logical to assume that if you thought about something then so too have many other people thought about the same thing, then this must be a pretty serious issue. What the Unix and Linux open source community needs, from a standpoint of continuing to bring in new users from other operating system platforms and to continue keeping existing users, is to improve upon only a handful of products. The question I hear from many people, and mind you I am much more of a Windows user at this point than a non-Windows user, is this: Why should I move to another platform when there aren't very many great products like Office 2000 and games like Madden Football 2002 can't be played on anything other than Windows (not sure about Apple products)?

The other, perhaps more persistent, gripe I have with the Unix and Linux product world is the poorly written documentation. Now, granted I don't know a lot about those products and I don't consider myself a really good writer or one that would enjoy spending hours upon hours documenting a particular operating system or product. What I do know is the documentation I have read is outdated, not really applicable to the task at hand. Okay, okay, perhaps what I am reading could be </i>slightly</i> changed to fit the task at hand, but therein lies my point. Well written documentation is both intuitive AND accurate. Sometimes, and I think this is quite funny, I get the feeling that Unix and Linux folks get an intellectual high from reading documentation that isn't straightforward. Some would call this hacking their way around, or better put "just try different things". Well, that is a suggestion I have gotten a lot and it is a poor piece of advice. There is really no reason that documentation can't be written accurately (so, one doesn't test his program throughout the stages of development either?) and intuitively (if you expect a lot of folks to have working, stable, friendly machines). Sadly, I don't think that a lot of Unix and Linux users or developers care about this. Why is there not a piece of documentation out there that gets someone's FreeBSD machine set up as a gateway, router, server and firewall? I have looked over the documentation, and since I do know how to follow instructions and I have still not satisfied my FreeBSD goals, then I firmly believe the documentation is not well written. tk, this is why I won't rescind my opinions of FreeBSD. I could care less that the founder of FreeBSD or any other developer in FreeBSD might be hurt with my posting of the truth, what really matters is the user. Until more people in the Unix and Linux world wake up and smell the coffee (I'm short on cliches), then things will continue to be status quo, we'll just continue to see more and more products of the same genre and function come out to the public, with none of them actually maturing to any great degree. Worse, the gap between Windows popularity and non-Windows popularity won't get much smaller, if at all.

Back to the topic of translating what the Unix or Linux newbie (to the operating system or to a function of the operating system) reads to what he does to his working environment. I don't need to do any guessing, nor should I have to fiddle around with settings. Just get the user's FreeBSD machine installed and configured, then let him tinker around the next time. At least he has a working machine to begin with. That alone is enough motivation to want to learn more about Unix (since I am on the topic of Unix at the moment), and who knows? Perhaps he will want to know more about a specific function of FreeBSD like firewalls. Then, assuming that he wants to write some software, perhaps he might decide to write his own version of a firewall and then later release it to the public.

Rather than look for others to agree with me, I think it is more important to encourage others to utilize their documenting skills to produce better instructions for the end user. Let's worry less about quantity of documentation, and worry more about quality of documentation. Perhaps we might be able to use a CVS of sorts in documentation. That way, when a user gets stumped, the documentation can be checked for accuracy or deprivation of detail, and the documentation will be updated so that the user and those who later read the documentation will have an easier time at installing, configuring, using and maintaining FreeBSD, or any Unix or Linux variant for that matter.

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!