The good old days

Alex has a post about laziness of developers. At least that’s the part I wanna focus on. He is wondering why people used to be ok with fixing the build but now they are “are unwilling to try out new things”.

I think it’s not the developer seniority he points out that’s the problem. At least it’s not the only problem. There is two more points. The first is the size of the project. People used to understand how all the software on their machine worked and what it did. I used to build an LFS and had looked at all the files in /etc. These days ai Can’t even get on the net anymore if NetworkManager doesn’t do it. And that’s not because I became stupid. It’s because I’d need to know the wireless extensions, wpa, hotplug and hal, and not just the right ifconfig line.
The second issue is the general quality of the software. People remembering the time of October Gnome know that problem: applications used to crash or not build. Fixing that was mostly easy. (This had the side effect of a low barrier of entry that helped attract lots of people, but that’s another story.) Today software is expected to be translated, crash-free and easy to build. Various distros are annoyed at libswfdec not having a stable API. 5 years ago people would have laughed at that requirement. So because all the other software today is better, people expect new software to be better, too. You can’t impress people with DOS games anymore.

The approach I’m trying to take in this laziness problem with Swfdec is pretty easy, and is probably the same as for all software in development, but it should be spelled out. I think some people might not have realized this, both people interested in helping or just random people commenting on your software. Here it goes: The most important people are the people working on the project. If the developers have to jump over too many hurdles, they’ll not get stuff done and that is most important at this stage of the project. So if the developers want to use git, the software will be hosted in git. The second most important people are testers and packagers, i.e. all the people that directly work with the source code. The normal user running the application comes last. This is for quite simple reasons: There’s more testers than users – or at least almost as many – and they are a lot more important for the project. They find loads of bugs, report them and help in fixing them. This order of priorities can be seen in the current features of Swfdec: There is an internal debugger, but no stand-alone player. There is the possibility to download movies in the plugin (You need the files to debug them), but it doesn’t do any sort of preferences.

When the project grows up and the number of users increases, this will gradually shift. You can see this with mature software such as Gnome: Not surprising the user is a way more important thing for new releases than adding cool new features. You can of course also notice that such user-friendly software advances way slower than unstable software where developers can change everything to their heart’s content. Both kinds of developments have their place. And the cool thing about it from the users’ point of view is that they can influence the state of a project: The more people use it, the more user-oriented it will become.