Slashdot Mirror
Contributing To a Project With a Reclusive Maintainer?
zerointeger writes "I am still fairly new to programming in C, but I was asked to extend an open source authentication module by my employer. The project is complete, testing has been done and it works as designed. The extension/patch I have created is fairly robust, as it includes configuration options, help files, and several additional files. The problem is that I have been unable to make contact with the current maintainer about having this feature added. I think the only reason I'd like to see this included is to prevent any patching of later revisions. A few others I have spoken with agree that the patch would benefit administrators attempting to push Linux onto the desktop, as we have done at the University that employs me. Has anyone else submitted patches/extensions to what seems to be a black hole?"
Sometimes OSS is a lot like butch lesbians. Take your question, for example:
Has anyone else submitted extensions to what seems to be a black hole?
Yes, sometimes a strap-on is precisely what is needed to fill a black hole.
But I digress.
What is the specific project you're fixing up? Is it fairly frequently updated by the maintainer?
That is really the point I think you need to figure out. If the maintainer has disappeared and does not update the package, then there's really no point in involving that person at all. He isn't the maintainer; you are. The only problem is, as you pointed out, if the package is updated and your patches aren't included, you'll need to provide patch updates to any of your users.
However, that said, what is more important to you? This package or your time? You don't work for the project, you work for your employers. Release this patch to whomever you like and give them the source. There's no reason you need to kill yourself trying to keep it updated if it works great for you now on the project version you targeted.
Either the official maintainer has lost interest, in which case you can simply fork the project, or
I am still fairly new to programming in C (...)
...University that employs me...
He looked at your code, and decided that some noob at a university wasn't worth flaming. This is a fairly common attitude among open source projects. You'll quickly develop a very thick skin.
Welcome to the OSS world, where maintainers disappear off the face of the earth, "unfun" parts never get updated, and projects die out to leave only stale Sourceforge pages dating back years.
Is the maintainer replying to other mails on the list and just ignoring this patch? Presumably he already sent the patch to the list, or there would be no way of getting it accepted (an email with attachments from someone who is not an existing correspondent is likely to be blocked as spam). Are other people on the list interested? Do any of them have commit access?
If other committers like it, then get one of them to commit it; the maintainer, if he wakes up, can always revert it. If no one else has commit access, are other people active contributors? How do they get their patches accepted? If the maintainer isn't replying to them either, then maybe he can persuade some of them to maintain a fork and accept his patch.
If the maintainer is awake and alive but just doesn't like his patch, then his best bet is to make a simpler version that exposes some public interfaces that allow extensions like his to work and to publish his code as an unsupported plugin.
I am TheRaven on Soylent News
FOSS has no way to deal with a project's sole maintainer dieing. Especially if the maintainer uses a pseudonym on the web. If the maintainer has a real name, try to get a hold of him via phone directories, etc.
If you can't get a hold of him after a reasonable effort, certainly fork the code.
The main issue then becomes, when can a new maintainer take the trademark/name of the old project without expressed permission of someone who cannot be reached in a reasonable time period and may be dead?
Help! I'm a slashdot refugee.
While forking is an option it can be a lot of work for little reward if noone picks up on your fork.
I'd say the first thing to do is try to figure out the following (some of theese will probablly overlap in thier answers)
1: Why is the maintainer not responding? is it because they dont like your patches, because they are overworked or simply because they are no longer involved in the project at all
2: are other users of the project experiancing similar problems.
3: is the project included with major linux distros (debian, fedora, suse etc) and if so what are they doing.
4: when was the last upstream release and does it look like there will ever be another one.
If you do fork you don't want to do it alone, if at all possible you want to get the distros and as much of the userbase on side as you can first.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
I'm the creator/developer/maintainer of a lot of OpenSource projects and sometimes you just can't seem to keep up or you find that life outside of OpenSource keeps dragging you away from getting around to applying patches.
To be fair a lot of the patches I receive are very minor and could be applied in seconds as well as verified but then there's also the whole update announcements process and all the documentation changes too. After a while you find you get to spend a couple of hours every 3 months on a project where you cobble together all the patches, sort out the docs and lump-release it. Yes, it's a bad way of doing things but often when the code is a decade old there's not a lot of compelling drive behind maintaining things at a prompt rate... .especially when you're already scratching to keep up with all the bills and other "real life" things (partners, cars, social comittments blah blah blah).
Anyhow, don't take it personally, just send another message periodically and eventually the maintainer will either snap or something. . . .a lot of us simply forget, yes, it's as simple as... now where did I put my coffee? :)
Another reason why the maintainer might not be responding: It's August, and people are on vacation and otherwise doing family-related stuff. Most open-source projects are done as a hobby, and in general August is a terrible time to submit patches to these kinds of projects. Wait until September and try again.
What are you a Windows programmer? I have never heard of Software having a "Mean Time To Failure" but then I am more of an Administrator and haven't done much QA.
You seem actively bitter about the possibility of forks while explicitly choosing a license that not only allows them, but makes it so simple that it basically encourages them.
Actually, I think it goes deeper than that.
Most people don't *want* to fork projects. Your average contributor is a career developer who's probably being paid to do something else entirely, and only contributed to the project because they needed some functionality to get their job done. Alternatively, they're hobbyists, in which case taking on the responsibility of maintaining a fork isn't something most people are interested in.
Instead, the reason forks happen is because the maintainer is, for some reason, hostile to the wishes of some not-insubstantial portion of their user base. In this particular case, it appears the OP is actively *annoyed* by people requesting features. Well, big surprise that, in such a situation, people are likely to fork your codebase: given the option between maintaining your own fork or dealing with a hostile maintainer, forking is obviously the best solution. And so the OP, rather than, say, being less hostile to and more cooperative with his user base, chose to simply take his ball and go home.
Fundamentally, it's an attitude problem: some people see software development, and OSS in general, as a collaborative process, and enjoy working with others, accepting contributions, etc. Others, however, see users and potential contributors as a nuisance and something to avoid. Big surprise if the latter group choose to obviate OSS in favour of a closed development model.