Wandering Thoughts archives

2013-07-10

Knowing when to go your own way with open source programs

Dmenu has become one of the core parts of my custom environment. The other day I finally got around to adding a feature to it that I've been wanting for a while, one that opens the door for making my environment subtly nicer. Given that dmenu is an open source program, the responsible thing to do would be to go the extra distance to update the manpage and so on then submit the change upstream.

I'm not going to do that, but not for the reason that you might expect.

A while back I made some other changes to dmenu and sent them to the upstream mailing list, where they created not so much as a ripple. I'd scanned the mailing list for a bit by then and so this lack of reaction didn't particularly surprise or annoy me; instead it cemented my quiet opinion that the dmenu developers and I had different interests and visions of dmenu. My changes got no reaction because the developers found them neither offensive nor interesting.

This sort of difference in views of a program is completely routine. When it happens there is no real point in trying to feed your changes upstream, because they aren't wanted (at the best they're simply uninteresting; at the worst they actively go against the developers' vision for the program). Trying to push your changes upstream anyways is a waste of time for all concerned and risks irritating the developers and ruining any good relations you might have with them. Instead the thing to do is to consciously go your own way with the code. Accept that your changes will never be merged upstream and do whatever you want to (including things that you want but that are violently against how the upstream developers like things).

This is why I'm not going to be trying to send my latest dmenu changes upstream; I don't think they're any more in line with the developers' vision for dmenu than my original changes were.

If you modify open source programs, developing a sense of when this is and isn't the case is going to be quite useful (if only to keep you out of flamewars on project mailing lists). I don't have any particularly strong suggestions except that you really need to know the project's culture before you start sending them email. Lurking on their mailing lists or what have you is highly recommended.

(Generally I think that the more hackish and brutal my modifications to the code are the more likely I am to be doing something that's against the developers' vision for the program.)

PS: it's my stereotype that the larger a project is, the less interested it's going to be in my modification. Firefox or the Linux kernel? I can forget it. A small one-person program? Highly likely to at least be willing to talk to me, although they may well still say no.

programming/GoingMyOwnWay written at 01:43:39; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.