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?"
Money makes the world go round (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.
What is your definition of "robust"? (Score:4, Interesting)
I saw you wrote this:
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.
black hole (Score:3, Interesting)
Are you saying that mail to the maintainer remains totally unanswered? Is there any activity on the mailing list? Or are you saying that the maintainer is simply not responding to your request to include your particular patch?
I maintain several open source projects, and there are many reasons why I might not include a patch: I may not understand it, I may not want to maintain it, it may break other features, it may conflict with future changes, it may violate the coding standards, the license may be unclear or incompatible, the patch may have been generated incorrectly, etc.
I think Launchpad actually has one of the best systems for dealing with this because it allows anybody to submit patches and new versions and the community can vote on and select patches.
Re:Fork it! - not funny (Score:3, Interesting)
Similar Story (Score:4, Interesting)
I've lived a similar story a while back. I was using a perl module from CPAN for a customer project. During the implementation I found some bugs/limitations. After getting in contact with the maintainer he sent me some patches to fix my problems. I used those and my project went into production.
A couple of years later we did migrate the application to a new server and I reinstalled the perl modules from CPAN. I found that the patches I got never made it to the CPAN repository. I still got the original patches and used those to get my project shipshape again.
In parallel I tried to get in contact with the original maintainer, but I never got a reply. It looked like he dropped off the planet. After a while I applied for co-maintainer status of the module on CPAN. This was granted when I could plausibly demonstrate that I tried to talk to the original maintainer. Since then I'm now the 'official' maintainer of the module and do integrate patches and help users.
We don't know about your modul en and its infrastructure (homepage., mailing list, etc.). Perl modules live on CPAN, so it is a good start to start there. You'll have to see where your program lives and go from there.
Markus
Never worked for me in the past (Score:5, 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.....
Re:Just fork it (Score:5, Interesting)
Re:Off topic: What's to a name (Score:1, Interesting)
IRC dead? Oh no, not by a long shot. It's doing extremely well.
The user interface of programs like Irssi and BitchX is simply really good.
Let's you focus on... well, chatting.
This is why I no longer open-source my projects (Score:5, 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.
Re:Death. (Score:5, 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).
Re:Never worked for me in the past (Score:3, Interesting)
Perhaps I should point out that when the maintainer is not MIA, but otherwise disinterested, this might actually work quite well. Never had a chance to pay someone else in this way, but did have the privilege to receive funds in order to solve a specific bug in one of my projects.
This is a big problem in the Python world. (Score:5, 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.
Re:This is why I no longer open-source my projects (Score:3, Interesting)
You're certainly free to distribute your software however you please, but if these were your feelings about open source software --
-- then I honestly don't understand why you ever decided to open source anything to begin with. 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.
Re:This is why I no longer open-source my projects (Score:5, 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.
The reclusive maintainer (Score:4, Interesting)
People get busy in their real lives, and open source projects are usually a low priority next to putting food on the table, trying to get laid etc. Another problem is the paucity of good developers involved in open source projects relative to the number of people using them. There is a definite learning curve in these languages. I have been working with C language for 20 years now (initially making small programs to make C programs compile on my particular OS) and on some level I still don't really understand pointers and memory - in fact I know I don't because I missed those questions on a recent examination.
Some people have been saying to fork it, but then you have to take on the burden of all of that. I would say definitely think before doing a fork, are there enough developer man-hours (person-hours) out there, including myself, over the next several years that will work on this project that will make a fork necessary? You don't want to fork a dead-end project into something that's just going to become another dead-end project. On the other hand, if there's a multi-year commitment from yourself (and maybe others) and the maintainer has disappeared completely for weeks and months on end, then maybe a fork is in order.
Re:This is why I no longer open-source my projects (Score:2, Interesting)
I like to think that my bug reports and feature requests are helpful. Certainly I intend them that way, though I suppose it's easy enough to imagine some maintainers think otherwise.
There isn't a sharp line between feature requests and bug reports. Personally, I take the liberal stance and say that "if it confuses the user, it's a bug", but some differ. Some strange people even write specifications and believe that "if it meets the specifications, it's not a bug." I can't agree with that. If a program misbehaves but meets specifications, that's a bug in the specifications. And, if the specifications are wrong, then you need to change the code anyway, just as much as if the bug were in the code.
Re:Never worked for me in the past (Score:3, Interesting)
It worked for me. I think the title of my email was "I'd like to send you $500"
I got a reply the next day. Within one week he had $500 and I had software with the additional functionality I needed. The functionality was included in the future release of the package and everyone benefits.
There is truth to the saying "Money Talks"