Troubleshooters.Com and T.C Linux Library Present

The Politics of Dependencies

Contents

Introduction
My Reply to the Assertions
Ooooh, I'm Shaking in my Boots
A Suggestion to Open Source Developers

Introduction

This web page was born after I took just a little too much abuse on the LyX mailing list. I had griped that the dependencies for Lyx 1.5.3 were very difficult to work around on my Mandriva 2007 setup. This happened in February 2008, so it wasn't like I was using an ancient distro.

In hindsight, perhaps I should have muzzled my frustration a little. But compared to the personal insults thrown at me by a small minority on the LyX list, I think my behavior was angelic.

~-~-~

Once upon a time I used a program called icepref to set my Icewm preferences. That program was abandoned in favor of a "better" program, called IceWM Control Panel, that used PyGtk "version 1.99 or later". My Mandriva 2006 Linux distro came with an earlier PyGTK, and installing a later one proved to be a dangerous and rickety excursion.

An email to the program's author didn't go well. When I complained about the specificity of the dependency, as I remember he said some bad stuff about me (for the life of me I can't find the email). I later pulled up this gem from the project's website:

"If you are using a Python version lower than 2.2 and are too lazy to upgrade, use the "binary" distribution of IceWM Control Panel, or don't bother at all.

Too lazy? Nice tude, dude!

That insult to the unknown user still exists, on 2/20/2008, at the project's "system requirements" page at http://www.phrozensmoke.com/projects/icewmcp/sys_req.php.

I started making my own front end to the IceWM preferences file, but stopped when I found an old copy of the now ancient IcePref. Today, with very little trouble, I could use my AAuSE techniques to create a text based IceWM preferences file whenever I feel like it. It would be a 1 day effort.

You might be wondering what ever happened to the IceWM Control Panel project. I'm wondering too -- finding the project's home page required significant Googling, and the latest update information I've been able to find on it is 4/29/2005. I can't say for sure that the project died, but it's not what I'd call wildly successful, considering at one point it was recommended by the IceWM project. Could attitude have something to do with its plunge into obscurity?

In the last six months, in various distro and application discussions, I've heard statements similar to these:

Users shouldn't compile programs!
If you're not smart/persistent enough, don't compile, get a binary!
Compiling is the distribution packager's responsibility, not the application projects!
Just apt-get install it!
Use Gentoo!
Use Debian!
It would have been harder to write the app with an older version of the tool!
Look at all the nifty features you get because we used a late version of the tool!
Lots of people get it to compile!
It's free, so if you don't like it write it yourself!

My Reply to the Assertions

Here are the statements to which I'm replying:

Users shouldn't compile programs!
If you're not smart/persistent enough, don't compile, get a binary!
Compiling is the distribution packager's responsibility, not the application projects!
Just apt-get install it!
Use Gentoo!
Use Debian!
It would have been harder to write the app with an older version of the tool!
Look at all the nifty features you get because we used a late version of the tool!
Lots of people get it to compile!
It's free, so if you don't like it write it yourself!

Let's review some of these assertions...

Users shouldn't compile programs!

That's a new idea. A few years ago, a big selling point for Linux was that users could compile their own programs, so that if they needed things a little different, they could do a little studying, change a few lines of code, and compile the program.

If you're not smart/technical/persistent enough, don't compile, get a binary!

Hey, I like binary packages as much as the next guy, but being completely dependent on packagers makes me a little nervous. I like compilation as a plan B.

Oh, and unless you know me very well, don't infer anything about my intelligence, technical knowledge or persistence. Perhaps it's just that I don't like dinking with tool packages that form a substantial part of my computer's foundation, just so Open Source developers can prioritize the latest and greatest over backward compatibility.

Compiling is the distribution packager's responsibility, not the application projects!

Hey, I like binary packages as much as the next guy, but being completely dependent on packagers makes me a little nervous. I like compilation as a plan B.

Just apt-get install it!

I don't have Debian, and I don't have broadband. Perhaps you could fault me for not having Broadband -- I live in a metropolis where decent broadband can sometimes be bought for $45.00/month. So you can fault me for griping about having to download megabytes of updates just to make one program work. But a big part of America's population lives in the country, where there's no broadband available. The "just apt-get install it" philosophy marginalizes those people, which in my view is in bad taste.

Use Gentoo!

Yeah, I've got all the time in the world to compile everything.

Use Debian!

I happen to like Mandriva. I've used it since 2000. Ironically, the original decision to go with Mandrake, as it was called back then, was because it was one of the few distros with LyX ready to run.

Yes, Mandriva + dialup makes it much harder to upgrade large chunks of my OS. But I really don't see why developers can't use tools compatible back to 3 year old distros. That just doesn't seem too much to ask.

It would have been harder to write the app with an older version of the tool!

No doubt it would have been harder. But it would have been easier for a big portion of the potential user base. When I took programming classes, they taught me not to make it harder on the user in order to make it easier for myself. I carried that on into my Open Source projects.

I'm not saying there's a need to be compatible with five year old distros. But look at the situation. At least with CD/DVD based distributions, the day the new distro version comes out, a lot of the tool packages (Qt, PyGTK, gcc and the like) are already almost a year old. Few whose computers are mission critical upgrade the OS the first couple months after the new version comes out, so by the time it's loaded on your box the tools could be a year old. If the user goes 2 years between OS upgrades (I think that's reasonable in some cases), toward the end the tools are three years old. Why not maintain compatibility back 3 years?

In the case of the IceWM Control Panel, I bought Mandriva 2006 in the fall of 2005, and by April 2006 the IceWM Control Panel required a later version of PyGTK than released on Mandriva 2006. Folks, that's just plain wrong.

Look at all the nifty features you get because we used a late version of the tool!

Does me a lot of good if I can't compile it. Might as well use two tin cans and a string.

Lots of people get it to compile!

That's great for them, but it doesn't help me much. Or is this assertion made just to imply that maybe there's something wrong with the way I administer my computer?

It's free, so if you don't like it write it yourself!

I just might do that. It's free software. I could grab the tarball, change the code, and fork the project.

Of course, that's not how I'd write it myself. If the project was simple enough for me to fork and continue, it wouldn't need the likes of PyGTK, Qt, or WxPython. No, what I'd do would be to create a minimalist app to do what I need.

After a few rather nasty personal comments toward me, and toward a guy I know, on the LyX mailing list, I'm evaluating the possibility of creating a VimOutliner front end to LaTeX. VimOutliner is GPL, and there's another GPL project called vimlatex that, from what I understand, does a great job of formatting and color coding LaTeX. Combined with VimOutliner and several scripts to parse layout files, and other scripts to convert the VimOutliner outline into LaTeX, I could do it if I wanted to spend the time.

Will I do it? Probably not. I've used LyX since 2001, and won't dump it because of a few personal insults. But for the future, LyX alternatives will be on my radar screen. Rolling my own LaTeX front end is a plan B.

Ooooh, I'm Shaking in my Boots

Oh my! Steve Litt's gonna write a LyX substitute and kick LyX's butt! Oh my!
Let's face the facts, a VimOutliner LaTeX front end is no threat to the LyX project. VimOutliner probably has a few hundred or a few thousand users, much fewer than the multitudes of LyX users. A VimOutliner front end is attractive only to sophisticated users willing to trade pretty for typing speed, versatility and installability. Steve Litt's just one guy.

But when developers get arrogant (and it was only a small minority of developers that got arrogant during the LyX thread), they blow off more than just Steve Litt. A user here, a user there, and pretty soon you've blown off a significant source of users, developers, documenters and evangelists.

Those ignoring history are bound to repeat it. In early 2000, the Smoothwall project pretty much owned the Free Software dedicated Linux firewall "market". But apparently several people were dissatified with the way the project was run, and forked it, calling the fork IPCop. I have no usership statistics, but the vast majority of people I know running a dedicated Linux firewall today use IPCop.

In 2004 the IceWM Control Panel was recommended by the IceWM project. Today the IceWM Control Panel website's last update is 4/29/2005, unless there's another web page somewhere. Could their plunge from popularity be because of propensity to require newer-than-distro PyGTK, their treatment of users emailing problems with installation, their "don't do it if you're too lazy" attitude? Could be.

Perhaps the originator of the IceWM Control Panel originator just went on to other things. Happens all the time. I pretty much quit the VimOutliner project two years after originating it. But during the project's first two years, I was good enough at working with others that users became developers, and one of the developer took over as maintainer and did a better job than I ever did. How users are treated can make a difference in a project's long term success.

A Suggestion to Open Source Developers

We all get arrogant sometimes. Face the facts -- we developers do things the general population can't even dream of. We give life to naked chips. Applications spring from our brains.

At our day jobs, arrogance buys us a dank dark room in the back of the warehouse, where we can't offend anyone. That's the fate of the excellent arrogant developer. The arrogant developer who's just average goes straight to the unemployment line.

Nobody gets fired from Open Source development, so you can be as arrogant as you want. But don't be. It's not good for the project. It's not even good for your image.