Sunday, January 2, 2011

[This (very long) post contains a certain amount of frustrated swearing. You have been warned.]

Open source applications usually face one of three fates:

If they’re not popular, they will be abandoned and forgotten.

If they’re merely useful on occasion, they stagnate.

If they’re popular and used often, they will get bloated beyond both recognition and usefulness.

I’m going to talk about the third one.

A developer has an idea for an application. There’s a certain task he needs help with, and nothing out there really meets his needs. So he decides to sit down and design an application that will perform the required functions and help him achieve his goals.

He decides that he will open source the code, for whatever reason. Maybe he’s an idealist. Maybe he’s a moron. It doesn’t matter, he just does it.

The application proves popular, and people start coming to him with requests for new features and bug reports for existing ones. Proud of what he has created and more than happy to help others, he starts spending more and more time working on his app.

He has a vision of what the application is supposed to look like; he sees the big picture and where all the features—both current and future ones—fit in. Some people disagree with this picture, but that’s their problem; he likes it. He thinks it’s the bee’s knees, the cat’s whiskers and a bottle of Johnny Blue all making sweet, sweet love together. Basically, he thinks his view of what it’s supposed to look like is fuckin’ A.

He also realizes that any piece of software can’t just keep piling up obscure features; there’s a certain threshold of diminishing returns where the new “features” start getting in the way of using the old ones even for the old-timers, and the new users have no fucking clue what they’re looking at. It all just becomes an ungodly mess of buttons, windows and menus that no one sane can use to get any sensible work done even after reading through a 500 page manual.

For a software application to stay away from bloat, the features added need to be useful for most of the users; not for just a vocal minority, and certainly not for just a few. Every new feature you add makes it slightly harder to use the old ones; it adds to the noise and eventually makes it difficult for the user to find what he wants and impossible to discover it through exploration.

All of this entails saying “no” to the requests that could otherwise be considered sensible, but that just don’t “jive” with the idea of what he’s trying to build. For instance, a request to “play FLAC encoded audio files” would make sense if he were building a music player, but makes somewhat less sense for an accounting application. Again, a request for a “counter that would track the number of noobs owned”; great for Unreal Tournament, less great for an FTP client.

But these requests aren’t the problem. The requests that are the problem are the ones that are useful to the person requesting them and maybe five other people.

So someone comes along and says: “I work with romance novels every day. My publisher demands that all the text backgrounds be bright pink. Now, I could select the text in every chapter and apply the color to each of these, but my life would be much easier if the main toolbar had a ‘Make all backgrounds pink’ button. Could you add one?”.

Now, what our developer wants to say is: “What are you, fucking retarded? Of course I’m not going to add that. Stop wasting my time. GTFO”. But being impolite to strangers is not something he’s willing to do (especially not over the Internet; there's too much unkindness here as it is), so he merely responds with: “No, that would not be a useful feature”. He understands that the person who’s asking for this would really find it useful, it’s just that no one else would.

The biggest problem are the people who come in with obscure feature requests like these but that are also willing to implement them themselves. This being open source and all, they’re willing to write code to get them in the mainline releases. It’s hard to say no to these folks, but a crappy feature is a crappy feature no matter who writes it. So he still says no, but hey if you’re willing to write code, the issue tracker is full of accepted feature requests you could implement. But the other dev doesn’t feel like it; he just wants his one issue in and doesn’t have the time for something else. And our original developer can respect that, honestly. Working on something for free purely for the benefit of others instead of spending the time to, say, watch a movie or read a book requires an unfortunately rare amount of altruism.

And probably stupidity and/or naiveté.

Ligis becomes even more popular. The more popular it gets, the more feature requests and bug reports that are actually valuable start coming in.

For our intrepid developer, this reaches a point where there just isn’t enough time in the day to both work on Ligis and to fulfill his other responsibilities in life. Or he just becomes too stressed out to work on it. Or he starts hating it all. Or he just flakes out. Or whatever. Again, it doesn’t matter; for some reason, he decides to stop working on it and hands off the reins to a new maintainer.

The new maintainer does what most maintainers do: he fixes the major bugs as they’re reported and maybe adds a minor feature or two. He pushes a new release once every six months, tops. He doesn’t add major features since he doesn’t have the time it would take to implement them. Hell, that’s the reason why the original developer left.

But now random people start showing up willing to work on Ligis. The maintainer gladly accepts their help. The new devs start adding the features they want, not necessarily the features that most of the users would find useful. I mean c’mon, this is open source, if the lusers want something done they should do it themselves. The new devs certainly don’t feel any kind of obligation towards them. And why should they? The new devs make drive-by changes they need and usually disappear afterwards. Even newer devs that also need some obscure feature replace them.

This goes on and on, until Ligis becomes freakin’ huge. Now it doesn’t merely have the kitchen sink; it has the sink, the toilet, the washing machine, the hair dryer, the bathtub and that little bidet shit the French use to wash their ass in. In twenty colors each. Yes, gold and papaya too.

The new devs were just throwing shit up against the wall until there was no more wall left, just a mountain of shit. Nobody had any vision of what the whole app was supposed to look like, no sense of scope. Scope? Fuck you and the scope you rode in on. I need my backgrounds pink and I need them pink yesterday.

A user of an old version of Ligis tries out one of the newer ones and feels the need to talk to the devs.

User: “Hi guys! I like the bidets in the new version. They really bring out the splash screen. I also enjoy the new mango-cyan color scheme. I have just one question though: I’ve noticed that there’s a mountain of shit where this wall used to be. There was a door in this wall, and I used to go through it every day on my way to work. Really useful door, that. Do you know what happened to it?”

Devs: “Oh the door is still there. We just didn’t have anywhere to put all this shit so we just piled it on top of the door. We have a couple of shovels in the back if you still want to get to it. This is our usual advice to the ever-popular how-do-I-get-to-the-door question. Have you read the Manual?”

User: “Uh… can’t you just remove the shit so that people wouldn’t have to shovel their way through?”

Devs: “Like we said, the door is still there. Take this shovel and the Manual, volumes three through sixteen; they will explain how to dig out a path. Watch for the landmines, the shark and the koala. The shark is friendly but the koala bites.”

User: “But why do I have to dig this long and winding path? Why can’t I for instance remove this pile of shit right here for good?”

User: “*sigh*, forget the door. Could you just fix this one obvious bug? Every time I hit the spacebar the whole computer reboots. It makes it difficult to type.”

Devs: “Yeah, we’ve been meaning to get to that one. Steve has been working on it since ‘95.”

Steve: “Still haven’t been able to crack it though. I can follow the call from the GUI layer to the new COBOL backend and through the kernel modules, but I get lost in the Space Shuttle diagrams.”

User: “Screw you guys, I’m going back to the old version.”

This is what happens when the original developers go away. True, sometimes it happens while the original developers are still very much active, but that’s a different issue entirely.

The point, please?

Why am I talking about all this?

I’m talking about it because this scenario1literally keeps me up at night. I’m able to justify the time I put into Sigil while I’m still in grad school, but that’s slowly coming to an end. I graduate soon. College takes a lot of your energy, but it’s in ups and downs. There are weeks where you spend twelve hours a day doing school-related work, and then there are “quiet” weeks. It’s during those that I worked on Sigil. Even then, I could only justify the time investment by making Sigil both my Bachelor’s and my Master’s thesis.

Since that’s all ending, it would be great to find some funding for future development. To that end, I’d like to add an OpenCandy powered advertisement to the Sigil installers for Windows2. It’s one of those “would you like to also install software X?” recommendations you sometimes see in installers. It would be turned OFF by default, meaning that if you just click Next, Next, Next, Finish, you will only ever install Sigil and nothing else. You can read an interesting CNET article about OpenCandy here.

Some key points:

As mentioned, any such “do you want to also install X” question would be set to NO by default (or deselected entirely).

The installers wouldn’t grow in size since the recommended software wouldn’t be included in the installer, only a piece of logic that would query the OpenCandy servers for a recommendation and download a different installer if the user chose to install that extra software.

No ads are displayed after the installer finishes. No ads would be in Sigil.

No malware, no adware and no spyware would be allowed to advertise. Developers get full control over the applications that can advertise in their installers, and can block anything they disagree with. An example of the type of companies/apps that currently advertise in the OpenCandy network are Kaspersky, Bing, Winamp, StumbleUpon etc. Respectable companies.

This OpenCandy service seems popular in the OSS world as a funding source. WinSCP uses it, Miro uses it, Audacity uses it.

OpenCandy would also advertise other OSS software inside the installer. That seems nice. Sigil is becoming more and more prominent, and I’d like to use that to promote other OSS apps as well.

Sigil is still free and open source. No proprietary code will enter the repository or Sigil.

Sigil functionality is not changed in any way, regardless of whether you install the extra software or not.

Mac and Linux users are not affected in any way.

Basically it’s just a single ad in the Windows installer. Nothing else.

But since the Sigil user community is something absolutely awesome, I’m asking for opinions. If enough of you come forward with valid concerns and arguments against this deal, I’m saying no. To tell you the truth, I don’t expect much from this deal in terms of revenue; peanuts per month, if that. But it would give me something to point at and say: “See? I can justify the time investment”. And hey, maybe it amounts to something one day.

You can post your opinions here in the comments or in this MobileRead thread. I’m not looking for a vote, I’m looking for a discussion. Bring your eloquence.