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