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?"
It's open source, so fork it and become the maintainer of the new version. When yours becomes more popular you will be famous, get offered large consulting fees, be able to afford blackjack and hookers, etc.
Since your employer paid you to create the patch, and since your employer will save money by not having you maintain a fork indefinitely, you should lure the maintainer with the strongest argument of all: money, paid by your boss.
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.
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.
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.
... tty layer was it?
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.
If the maintainer is French, don't expect an answer untill september 1st,
the project should be taken away from them
No need to be uncivilized about it. There should be a ceremony, with flags and banners and trumpets and horses. The bold new developer's name should be announced with accompanying fanfare, and he shall kneel in front of the wizened author (who should have put out his cigarette before these solemn rites). The sword edges should be dull, lest angry words from jealous unrecognized forkers be heard and needless violence ensue. I should stop now before this starts affecting my English henceforth
WARNING: Smartphones have side effects--most of them undocumented.
and politicians who don't represent the will of the people after the election should be impeached, disbarred ... ... ... .... ...
and companies who sign a contract and then go broke should still pay and fullfill the contract
and orphans should never get cancer
and all programs should be open source
and I should get paid for this
and
sorry - just getting frustrations out
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