Contributing To a Project With a Reclusive Maintainer? 162
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?"
Extensions and black holes (Score:3, Insightful)
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.
Just fork it (Score:5, Insightful)
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 world of OSS (Score:5, Insightful)
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.
Re:Publish patches (Score:5, Insightful)
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.
Re:black hole (Score:3, Insightful)
And how long did he wait? Maybe the maintainer is on a vacation. People have lives, and he's under no obligation to answer immediately.
Death. (Score:4, Insightful)
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?
Re:Fork it! (Score:5, Insightful)
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.
Re:Fork it! (Score:1, Insightful)
My project, my blackhole. (Score:4, Insightful)
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? :)
Re:Welcome to the world of OSS (Score:5, Insightful)
Better than a programmer disappearing off the face of the earth leaving code he wrote on a workstation backup in a closet somewhere, were it will never be able to be used by anybody else.
Re:Death. (Score:2, Insightful)
Sorry - this is too far from the truth to be caused by mere ignorance...
Obviously, FOSS cannot revive the maintainer (but neither can proprietary software projects). But in FOSS projects, the death of a maintainer will not (by itself) force the death of the project. The only thing that kills FOSS projects is lack of interest.
Anybody can step up to the plate and take on the role of maintainer, simply because the code is still available. If nobody does, then the project is likely to die. But that will only happen if nobody is interested enough to help.
Comment removed (Score:5, Insightful)
Private copy is not a fork (Score:3, Insightful)
I don't think he's already forked it. He has a privately held altered copy, and possibly makes the source available somewhere.
"fork it" implies you might have a different app name, hosted separately (even if "separately" just means a different zip file). In other words, not just changes the code. Forking implies becoming the new maintainer and setting up a way for users to get feedback to you instead of the original fork.
Of course, it's much easier to just get it included "upstream". If the base maintainer doesn't want people making mass changes to the code for whatever reason you got no choice.
Re:Welcome to the world of OSS (Score:3, Insightful)
I prefer stale sf projects to scientific papers that say they modified X (e.g. ns), but never show the code.
Re:Fork it! (Score:1, Insightful)
I would have said Natalie Portman and hot grits.
Get off my lawn.
Re:Just fork it (Score:2, Insightful)
Re:Extensions and black holes (Score:4, Insightful)
What is the specific project you're fixing up?
Not to mention you're asking slashdot. Somebody here could know the guy who maintains it, or at least know somebody who mentioned to them that he got hit by a bus.
MTTF (Score:4, Insightful)
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.
Re:This is why I no longer open-source my projects (Score:4, Insightful)
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.
Re:Welcome to the world of OSS (Score:2, Insightful)
If it is important enough then it may be written again. If it is not important enough then a stale sf.net page provides testimony to how unimportant it was.
Re:This is a big problem in the Python world. (Score:3, Insightful)
[Bang! There goes the modpoints...]
The C API for Python changes with each release of Python, and modules have to be updated and rebuilt for each platform.
That's stupid. If you were - as a community - to commit to a stable ABI then the modules would only need rebuilding when they are to take advantage of a new piece of API. That in turn allows developer effort to be spent far more wisely in areas where it can make a good difference. (The Tcl community has been doing this for a decade.) You can even leverage this to strengthen your packaging technologies too, but that's getting off-topic.
This process lags years behind Python releases. Often, the needed changes are minor, but short of forking and taking over maintenance of the module, there's no way to get them done fast.
That's why a production module shouldn't have a single maintainer (and preferably shouldn't have all maintainers be from the same organization). Like that, you've always got a panic button ready to be pressed in case something goes wrong.
There have been amusing moments. At one point, the maintenance organization for a module used in business applications was a World of Warcraft guild. At least they got stuff done.
I just hope it wasn't an interface to a RAID system that they were maintaining; that'd be just too funny for Sunday morning...
Re:Welcome to the world of OSS (Score:3, Insightful)
Nope. SourceForge is all AJAX-y and PHP-ized.
Archive.org only works properly with static pages.