Slashdot Mirror

← Back to Stories (view on slashdot.org)

Contributing To a Project With a Reclusive Maintainer?

Posted by Soulskill on from the pulling-a-davis dept.

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?"

25 of 162 comments (clear)

  1. Fork it! by Anonymous Coward · · Score: 5, Funny

    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.

    1. Re:Fork it! by petermgreen · · Score: 4, 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.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    2. Re:Fork it! by wigaloo · · Score: 4, Insightful

      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.

  2. Try sending to some distribution by Anonymous Coward · · 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)

  3. Money makes the world go round by Bananenrepublik · · Score: 5, Interesting

    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.

  4. contact the package maintainer instead by quitte · · 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.

  5. Just fork it by Anonymous Coward · · 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.

    1. Re:Just fork it by TheRaven64 · · Score: 4, Interesting

      Same here. One of our most active developers now was a complete n00b when he joined the project. I recently committed a big chunk of code to one of our core libraries written by someone who was a bit of a n00b. That took three rounds of code review, but at the end we got some really nice code and he became a lot less of a n00b, so everyone was happy. I could have written the code myself, but since there had been a TODO comment in the file that I added two years ago telling me to, it was probably not something I would have done for a long time.

      --
      I am TheRaven on Soylent News
  6. Publish patches by KarlH420 · · Score: 5, Informative

    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.

    1. Re:Publish patches by TheRaven64 · · Score: 4, Insightful
      Exactly. A lot of people have suggested a fork, which implies that they didn't read the question. The submitter already has a fork, maintained by his company (well, most likely just him). He wants to avoid the cost of maintaining a fork by getting his changes merged upstream. Unfortunately, he didn't give enough information for us to give the right answer.

      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
  7. What is your definition of "robust"? by BadAnalogyGuy · · Score: 4, Interesting

    I saw you wrote this:

    The extension/patch I have created is fairly robust, as it includes configuration options, help files, and several additional files.

    Your definition seems to mean "complete" or something along those lines. However in actual industry usage, robustness is a measure of software quality as tested. You may be providing a lot of configuration options, help files, and several additional files (what does this mean?), but are you providing well-tested, exception-proof code?

    What is your test matrix like? What is the MTTF among your users? How many users are actually using it?

    The patch you provide can be the most beautiful set of files ever created, but if the maintainer needs to fix all the bugs you created because you didn't test anything except the most obvious cases, then you aren't helping.

    Something to keep in mind as you graduate from university programming to actual industry programming.

  8. This wasn't something to do with the ... by kevingolding2001 · · Score: 5, Funny

    ... tty layer was it?

  9. Welcome to the world of OSS by Anonymous Coward · · 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.

    1. Re:Welcome to the world of OSS by characterZer0 · · 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.

      --
      Go green: turn off your refrigerator.
    2. Re:Welcome to the world of OSS by some-old-geek · · Score: 4, Funny

      My confidence brimmeth over.

  10. Yes, it happend to us by Sun · · Score: 4, Informative

    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

  11. Holidays by Anonymous Coward · · Score: 5, Funny

    If the maintainer is French, don't expect an answer untill september 1st,

  12. Re:Fork it! - not funny by Provocateur · · Score: 5, Funny

    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.
  13. Never worked for me in the past by Sun · · Score: 4, Interesting

    There were several cases in the past where I tried this. I cannot recall a single time where offering money brought back from the dead an otherwise MIA maintainer.

    The theory is solid, but I have never managed to see it work in practice. Perhaps their spam filter ate my "I WANT TO PAY YOU MONEY" email.....

  14. Yes and ... by OeLeWaPpErKe · · Score: 5, Funny

    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

  15. This is why I no longer open-source my projects by ugen · · Score: 4, Interesting

    I used to open-source everything I do. No more. My current project is closed-source (but free) application. While there are quite a few users, very few butt in with "extensions" that they feel absolutely must be there. No forking either - you don't get to take the results of my work, add a few things and distribute, creating confusion and incompatibility, which lead users to other products all together and hurt me (I don't care about the other guy). Don't like my design? Write your own damn product, it is a free country and you have access to gcc and vi :) just like I do.

    Incidentally, in my experience with open-source projects significant majority of user response email consisted "feature requests", usually written in demanding "you owe it to me" key. Now with a closed-source application, no such thing and quite a bit of feedback begins with "thank you for the great product" :) Now that's good motivation, and it keeps me working.

    1. Re:This is why I no longer open-source my projects by Abcd1234 · · Score: 4, Interesting

      I used to open-source everything I do. No more. My current project is closed-source (but free) application. While there are quite a few users, very few butt in with "extensions" that they feel absolutely must be there.

      Great, so in a case like this, where a user created valuable new functionality, you wouldn't benefit. Instead, you'd be stuck doing the work, or refusing to do so, in which case you'd lose a customer who'd be forced to move to a different product, instead.

      Basically, rather than ignoring useful patches, you now have to ignore users requesting useful features, who then just move on when you say 'no'. Yeah... that's much better.

      No forking either - you don't get to take the results of my work, add a few things and distribute, creating confusion and incompatibility, which lead users to other products all together and hurt me (I don't care about the other guy).

      How is that a product of being OSS? The issue, here, is very simple: a maintainer that's either non-responsive or MIA. If the maintainer were responsive, the changes would be added to the existing product, and everyone would be happy: the originator wouldn't have to maintain a separate tree, the maintainer wouldn't have to write the code themselves, and the other users would benefit.

      In fact, in this particular case, closing the source only does one thing: fucks the customer, as they're now forced to find something else, since they can't just take the code and alter it as they see fit.

      Now with a closed-source application, no such thing and quite a bit of feedback begins with "thank you for the great product"

      I'm sorry, but I have to call "bullshit", here. Whether or not you get feature requests has absolutely *nothing* to do with the license the source code is under. Either way, you have users with ideas about how the product should work. The only difference is that, in the case of closed source, the user can't just contribute code back to you. Instead, they have to wait for you to decide their idea is worth implementing (and then live with whatever implementation you come up with). That sounds like a lose-lose proposition to me.

  16. Be Professional, Patient, Assertive by desertcrevasse · · 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

  17. Re:Death. by adamkennedy · · Score: 4, Interesting

    > FOSS has no way to deal with a project's sole maintainer dieing

    Perl does.

    As usual CPAN has a long-established and regularly used method for dealing with issues like this. There's a process of handing off namespace control to new maintainers when previous maintainers go silent or die. With 7000 developers in the system, our experience is that a few dozen are going to die every year (although I imagine this will slowly increase as the median age creeps upwards).

    In practice, we tend to see one significant case of death or death-like symptoms a year that requires a little more hand-holding to do proper module hand-off.

    In the last few years, we've lost the maintainer of Perl's Tk bindings, a significant DateTime contributor, and a few years ago one of the largest CPAN authors quit programming to become a missionary in Japan and asked for new maintainers for all his work (that would be the "death-like symptoms" part).

  18. This is a big problem in the Python world. by Animats · · Score: 4, Interesting

    The Python world suffers badly from this problem. There are many add-on modules for Python that are written in C. The interfaces for databases, SSL sockets, and similar things one needs for basic web applications are third-party modules in Python. In most cases, the module has one maintainer.

    The C API for Python changes with each release of Python, and modules have to be updated and rebuilt for each platform. 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.

    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.