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?"
Try sending to some distribution (Score:4, Informative)
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)
contact the package maintainer instead (Score:5, Informative)
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 patches (Score:5, Informative)
It's OSS. Do what you like. (Score:2, Informative)
Personally, I'd try to contact the current maintainer, if any, first. Failing that, you could take over maintainership, fork the project, or simply publish your patches and update them as you would likely anyway. If you promise to maintain your patches people will expect you to do so, so you should be careful as to what you promise. Of course, unmaintained patches are much less attractive for others to use than fully integrated and supported ones.
List your options, choose wisely. Acquiring butch lesbians optional.
Fork it. (Score:4, Informative)
Yes, it happend to us (Score:5, Informative)
We ended up forking - mawstats [lingnu.com].
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
Re:Just fork it (Score:3, Informative)
Well, now, I disagree that such an attitude is common. I have never received such treatment by any project maintainer and would not myself do it for my projects. Whenever someone contacts me about a project I maintain, I always reply, even if it's to a total n00b.
Re:Death. (Score:3, Informative)
Yes it does. you set a dead-man switch. Just because the lead developer is too lazy to do such a thing does not mean it's a failure of OSS.
Plus, where in OSS does it say that I cant take over a project? check out the last CVS and continue. I bet there is a system in place at sourceforge to take over a project there if the devs on it's admin list are non responsive.
If anything it's closed Source that does not have away to deal with the maintainer dying. Most Close source people are paranoid that someone will steal their GENIUS in their code so they encrypt it and hide it. The thought to setting a dead man switch to them is nuts, they want their project to die with them.
Be Professional, Patient, Assertive (Score:5, Informative)
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
Re:Fork it! (Score:4, Informative)
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?
Re:Welcome to the world of OSS (Score:4, Informative)
You know... you can request a takeover of defunct Sourceforge projects...
Re:Death. (Score:2, Informative)
Trademarks need more care and attention than you seem to imply, especially the non-registered variety, as they aren't consistently the subject of the free (1,2,3,4) clauses of the license. See Firefox naming and branding, for example.
As with other sole-proprietorship operations, it may be difficult to externally determine if the project or product name is the subject of any agreements or relationships the original owner may have had with third parties. As a hypothetical, local business relationships may be based on the strength of the inclusion of $ProjectName because it was known to be authored by $OldMaintainer who is trusted, and therefore $OldMaintainer's code is trusted. As an unconnected third party from elsewhere in the world, it is likely that an outsider would have difficulty in discovering this information. If a customer enters into an agreement with a supplier which materially involves $ProjectName on the reasonable assumption (perhaps due to poor communication on the part of the new maintainers or one of the intermediaries) that it is $OldMaintainer's project and has not been altered by $NewMaintainer's contributions, which parties are responsible when the use of the current version produces undesired output?
As an example of trademark and branding considerations falling outside the strict trademark laws, how would you deal with the situation where someone who had taken over an abandoned educational Linux distribution had patched it so that it was LMOS?
Its not that complcated... (Score:2, Informative)
Commits to its version control system is good indicator of that. No commits for several months means its quite dead. Then forking/trying to take over the project(SF supports a procedure like that IIRC, I dont know about others) is only option. Taking over usually means getting contact with the original maintainer and that may fail, leaving only forking.
If the project is active there simply might not be enough developers to review the patch or adjust it if the review demands it. Or your patch may have issues that make reviewing it complicated. Often patches are submitted against a version long behind the development version and don't really apply any more.
For an active project there usually is one place where developers converge, often IRC or mail list. Finding that place and posting your patches along with willingness to improve it(sometimes its as simple as patch format) to meet the maintainers demands usually results in an easy merge.
Sometimes however, the extension/feature is not desired by maintainers and you will be told so and you would have to fork.
The best way to do such things is to contact the maintainer when you start developing your extension. It pretty much guarantees a merge at the end.