== Knowing when to go your own way with open source programs

[[Dmenu ../sysadmin/ToolsDmenu]] 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 ../sysadmin/ToolsDmenu]] 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 ../unix/FvwmKeyboardWindows]] I made some other
changes to [[dmenu]] and [[sent them to the upstream mailing list
http://lists.suckless.org/dev/1202/10851.html]], 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.