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?"
If its patches is applicapple to Linux, try to send to some of the Linux Distributions. They usually have good contacts to the upstream maintainers, and even if they have not, have ways to record some changes and share them.
(And that is where people that may take over upstream also most likely will look for patches)
talk to the package maintainers of a couple of distributions instead. packages.debian.org packages.ubuntu.com etc. should help you find the maintainers email addresses.
Publish the patches on the project mailing list, forum, or on your own website or blog. The most important thing is to get the patches out there. That will open it up to peer review and discussion. From there you have the possibility of linux distros picking up the patch and using it. Eventually the project may pick up your patches. A fork would be a last resort.
Use something like git and maintain your changes in your branch which you can push to e.g. github (substitute hg and bitbucket where appropriate). You'll have the added benefit of easy merging with upstream.
We ended up forking - mawstats.
Deliberations over whether to fork jawstats was a hard one. The extension was part of a project done for a client of ours. We ended up deciding that we did everything we could to contact upstream, and it was either fork or keep things to ourselves. Luckily, the client (who is the one paying the actual money :-) agreed, and this is the result.
If you have no choice, then you have no choice.
Shachar
We are involved in a similar effort to add features to mod_auth_cas. While the project maintainer is far from unresponsive, it's clear he has other responsibilities and attends to the project as time allows. We are making demonstrable progress toward having our features merged into the project, but the process has taken longer than anticipated. What has worked for us:
- Be Professional
We followed the recommended procedure for submitting the patch, have been responsive in addressing questions, and have tweaked the patch when asked. Throughout we've maintained an attitude of humility, which makes friends and influences people.
- Be Patient
Provide adequate time for your submission to be evaluated. Like so many open source projects, the maintainer probably handles the project in his "spare" time.
- Be Assertive
Inquire about the status of your submission regularly via communication channels the project provides. The frequency of your inquiries should be reasonable; nags are easily dismissed. Inquiries that express a sincere willingness to be part of the solution are particularly effective. Also, you may consider contacting other folks personally that may have influence upon the project. If you can't get the maintainer's attention, maybe you can get the attention of a trusted colleague who will encourage the maintainer to take a look. I believe this point in particular was helpful in getting our patch reviewed and acted upon.
Good luck. From a cursory review of your project goals, it sounds like your contributions would be sincerely valuable for pam_krb5. I'm pretty sure we could make use of it at our University.
M
Or you can upload it to a website, or the wiki if the project has one. Just make sure people understand what project it is useful with. I wouldn't fork immediately. Forking should be something you do as a last result because you feel you definitely need to take the project in a different direction (or a direction at all). BTW, why don't you mention what the actual project is?
Occam's razor is the blind faith in the natural selection of least resistance and in universal oversimplification. -- EF
You know... you can request a takeover of defunct Sourceforge projects...