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.
Sometimes OSS is a lot like butch lesbians. Take your question, for example:
Has anyone else submitted extensions to what seems to be a black hole?
Yes, sometimes a strap-on is precisely what is needed to fill a black hole.
But I digress.
What is the specific project you're fixing up? Is it fairly frequently updated by the maintainer?
That is really the point I think you need to figure out. If the maintainer has disappeared and does not update the package, then there's really no point in involving that person at all. He isn't the maintainer; you are. The only problem is, as you pointed out, if the package is updated and your patches aren't included, you'll need to provide patch updates to any of your users.
However, that said, what is more important to you? This package or your time? You don't work for the project, you work for your employers. Release this patch to whomever you like and give them the source. There's no reason you need to kill yourself trying to keep it updated if it works great for you now on the project version you targeted.
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)
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.
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.
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.
... 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.
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.
Use something like git and maintain your changes in your branch which you can push to e.g. github (substitute hg and bitbucket where appropriate). You'll have the added benefit of easy merging with upstream.
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
FOSS has no way to deal with a project's sole maintainer dieing. Especially if the maintainer uses a pseudonym on the web. If the maintainer has a real name, try to get a hold of him via phone directories, etc.
If you can't get a hold of him after a reasonable effort, certainly fork the code.
The main issue then becomes, when can a new maintainer take the trademark/name of the old project without expressed permission of someone who cannot be reached in a reasonable time period and may be dead?
Help! I'm a slashdot refugee.
Maybe the maintainer does not read his e-mails while he is on holiday. But who would go on holidays without reading /. daily...
If the maintainer is French, don't expect an answer untill september 1st,
"Has anyone else submitted patches/extensions to what seems to be a black hole?"
Yes. But getting your patches rejected by singularity shouldn't hurt your feelings.
Seriously, if the current maintainer (in name only - sounds like he/she's lost interest, or to use the modern euphemism, is "too busy"), can't be bothered to fulfill their responsibilities the project should be taken away from them.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
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.
I'm the creator/developer/maintainer of a lot of OpenSource projects and sometimes you just can't seem to keep up or you find that life outside of OpenSource keeps dragging you away from getting around to applying patches.
To be fair a lot of the patches I receive are very minor and could be applied in seconds as well as verified but then there's also the whole update announcements process and all the documentation changes too. After a while you find you get to spend a couple of hours every 3 months on a project where you cobble together all the patches, sort out the docs and lump-release it. Yes, it's a bad way of doing things but often when the code is a decade old there's not a lot of compelling drive behind maintaining things at a prompt rate... .especially when you're already scratching to keep up with all the bills and other "real life" things (partners, cars, social comittments blah blah blah).
Anyhow, don't take it personally, just send another message periodically and eventually the maintainer will either snap or something. . . .a lot of us simply forget, yes, it's as simple as... now where did I put my coffee? :)
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
Fixed the spelling (punctuation, actually) mistake. Thanks.
Regarding the name, I'll quote from my old home page. I'd just give the link, but I suspect this site will not remain in the air for much longer (most of it is quite out of date), so I'm quoting here:
So now you understand the reason behind my /. user name....
I should point out that I stopped using "sun" as a nick name, mostly because I figured the Internet had enough of its Xenophobia gone to allow non "Latin friendly" names. I also figured most people today are adept enough in the complex art of "copy and paste" to handle it.
Then again, who knows? Maybe with Sun bought by Oracle, sun.com will be free again and I'll change my mind...
Shachar
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.....
It's hard to not be reclusive when behind bars at San Quentin.
I guess you won't be coming back to slashdot then since it's running on messed-up failing software...
Just put it the code there with the right license, and referals to the previous work that you used as a base. If your changes are significant enough, they will get ported to the mainstream version; or your version could become the mainstream one by its own merits.
I don't think he's already forked it. He has a privately held altered copy, and possibly makes the source available somewhere.
"fork it" implies you might have a different app name, hosted separately (even if "separately" just means a different zip file). In other words, not just changes the code. Forking implies becoming the new maintainer and setting up a way for users to get feedback to you instead of the original fork.
Of course, it's much easier to just get it included "upstream". If the base maintainer doesn't want people making mass changes to the code for whatever reason you got no choice.
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
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.
and then learn to stop capitalizing university automatically.
Would you expect someone to talk about working at a Company?
If it is a SourceForge page or similar alowing for user submissions, then submit patches for each part of your work, and in the description for each give a link to a complete tarball of the source including your work.
This allows for the maintainer to easily pickup your changes, plus future users to locate your changes before they get merged upstream.
--
Thorbjørn Ravn Andersen "...and...Tubular Bells!"
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
... slashdot ... it's running on messed-up failing software...
Quoted for truth.
However, there is not necessarily any correlation between Slashcode being terrible and the fact that it is open source.
Celebrity worship is a poor substitute for Deity worship and costs more to boot.
What are you a Windows programmer? I have never heard of Software having a "Mean Time To Failure" but then I am more of an Administrator and haven't done much QA.
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.
Everybody is talking about forking it. T be politically correct and fair among genders, I suggest we spoon it instead.
Again another instance of why there needs to be some organizational standards and not just coding standards to the structure of FOSS projects. Every time I bring this up on Slash, I get my head bit off; but with all the noobs suddenly finding FOSS and jumping in to start and run projects it is becoming an increasing problem in FOSS. I suspect because those with the experience are progressively spread thinner. Every week there is another story on slash about some project or another where the top guys went AWOL and everyone is stuck. You just have to look around the FOSS landscape for similar examples.
Downstream and sometimes upstream providers and users depend on the stability and health of the projects to make decisions about their own projects. Companies and just end users need to be able to determine that a project is not going to implode in making decisisons.
We need a standardization process for evaluating how FOSS projects function. A FOSS ISO organizational certification or something to allow us to evaluate entire chains of software and the projects they depend on for projects internal stability, and not just the quality of the code produced.
I do appreciate the survival of the fittest / wild west mentality and how it produces superior code, but FOSS in general is maturing and the internal organization of FOSS projects can not be ignored for much longer. I am not saying we stop that, but as any particular FOSS project becomes critical to the eco-system, we should have some standards to designate what is and is not a reliable source of code or programs. Start with a simple grading and review system that evaluates the stability of the organizations behind any particular project.
Living in Chile
Need a -1 Unclever mod right about now. Though Redundant works too I guess.
I routinely take a few weeks to reply to mails if I cannot reply quickly and they require some work to be done. Naturally, some of those I wanted to respond to get lost in the infinitely extending inbox.
Despite my poor replying record, I still spend an average of >10 hours per week dealing with email. And I am not a maintainer of any (public) open source project; I simply participate.
I favour the Linus Torvalds method of inbox flow-control: if it's important, send the maintainer the same mail again after a week or so. Try again a week later. If your email covers multiple issues, try spliting up as the maintainer my have time to deal with one of them. If you're not getting an answer, there are lots of practical reasons which are easy to imagine... Especially if it's a project where the maintainer might get a lot of email, or where the maintainer might have very little time to work on it.
If you do resend an email, mark it clearly so the maintainer knows they can delete the earlier one without reading it; there's a fair chance it's been sitting in their inbox for a long time, making them feel guilty, and when they read your mail they are probably dealing with a batch of mail on related subjects.
Ideally, well run projects have a mailing list and other interested participants where things can be refined without the maintainer being a bottleneck. Small projects don't get that far though.
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.
I'm the author of a number of patches to a number of OSS projects, mostly security related. So, I would love to know what this "authentication module" is. Sounds like it might be PAM or maybe Apache related?
Over the last year and half or so, a major OSS routing package, Quagga, was largely on "auto pilot". The maintainer was not being responsive and outstanding patches were piling up and releases were over due. This project was, in and of itself a fork of an earlier project, Zebra, that had gone stale and been largely abandoned by its developers. Several months ago he popped up back out of the woodwork explaining that his job (that supported his work on this project) had been overwhelming and he had gotten way behind in things. Since then, most of the patches that had piled up in his queue have been integrated and several releases have cycled out and the project is now approaching it's first 1.0 release candidate. That project is alive and active once again but, before he returned some people were already starting to talk of yet another fork.
It happens and it can take time. If the project has a list, post to it and seek out some of the past contributors. Don't give up on him, he may be just extremely busy putting food on the table. The entire CentOS distribution was threatened by the absence of their lead (covered in other SlashDot articles). He showed up after all the publicity.
On the other hand, some projects deserve to die. A couple of VPN projects and crypto projects have been abandoned by their authors and maintainers and don't deserve to be resurrected (bugs, security holes, etc) even though they still had followers. Doesn't sound to be the case here but it's hard to tell without knowing what it is.
The username in the article links to pam-krb5-ldap.
Your title would have about a 50% of working had the project been mine. If the spam filter let it through, I would probably have read the message. If it marked it as spam, I would have been highly unlikely to have read it when scanning for false positives. I would probably assume this was a Nigerian scam of some sort.
At the very least, you need to put the project's name in the title.
Shachar
Create a web page somewhere that contains link to downloadable patches and a tarball of the patched source code.
You can continue to try contacting the maintainer, or a developer working on the project, but you may never find them.
Honestly: the time to try contacting the maintainer is BEFORE writing the patch. Many OSS projects prefer contributors to contact them first, it's preferable for work to get submitted in small chunks as it's being developed,
Rather than one huge power play submission representing massive changes to the code, which could take months to review.
Only for developers to immediately see things they don't like in your work.
Even if your contribution works 100%, you can expect the existing developers may want various things cleaned up or adjusted to match their style / coding conventions.
The existing developers may have other major work slated for the next release on their code repositories.
If your patch was against the stable version, it may now take a lot of work to merge your changes.
That's why you should publish first at this point. Even if you get a hold of the maintainer, it could be a long time before your code can get included into the development repository, let alone in a stable release.
I simply can't get myself to do any coding on my FOSS project for 9 months in a year. And then I do 3 months of frantic work, package Windows versions etc. (I think I'm bipolar III)
Fortunately, the SVN sysadmin allows many people to patch the code. So all the ideas (good and bad) are collected and the Linux users get to try them out.
I am maintainer for a project that is used in a subproject of mine. I am not involved much in the subproject so I'm just maintaining it becuase no-one else does. I have got atleast one patch that got stuck in the work queue for weeks. I *will* take a closer look to the patch and I will move this subproject to git (as the CVS server is so slow that its unuseable). Its not that I don't care or don't like the patches, its just that I don't have had the time to actually do it. sorry...
Even supposedly active, sponsored projects like Eclipse's JDT code seem to suffer from decent patches with proper regression tests being ignored for months. My only advice if you can't make the developer(s) take notice is to maintain your own branch / patchset. Forking generally is to be avoided if possible, particularly if you only want to augment the code or change tiny bits of it.
First, its important to decide if the project is active or not.
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.
I would say, just keep sending a reminder email occasionally. perhaps send one on the weekend when the guy/gal is less likely to be reading it after work.
I'm looking at it from the other side. People send me patches for my software, and I do appreciate it and think yeah I should incorporate that, but the thing is I'm usually reading those emails after getting home from work, and the last thing I want to be doing at that time is sitting back down at my desk to do something about it. It is just so easy to leave it for later. I often think I'll do it on the weekend, but then I don't get around to it. If I received and read an email about it on the weekend though, it might be a different story. I'm more likely to feel like I've got enough energy to incorporate the patch and do a release straight away.
France apparently also includes portions of North America as well.
I know a guy who grew up in the French town of St. Pierre. He and his friends used to take their jet skis on the ocean from their home to Canada from time to time (no, I'm not joking...JET SKIS...from France to Canada).
Sounds impressive, no? Well as treacherous as the ocean is in the area it isn't as outrageous as it sounds because St. Pierre, France is only slightly more than 10 kilometres (6 or 7 miles) from Green Island, Newfoundland, Canada. St. Pierre is the town in the french territory of St.Pierre et Miquelon--a small group of islands just south of Newfoundland (there is a "canada-france border" in the ocean channel between them). These French islands sit on the continental shelf so you are literally right--France LITERALLY includes portions of North America.
And, yes, August is typically peak vacation season, for both French and Canadians in the region.
And the point about teachers is a primary reason--if teachers are on vacation so are students, and as such families plan their vacations at this time to avoid tkaing children out of class. I'm on the other side of the continent and it's true here as well--july and august are the slowest months because of vacations (however they are busy months in some specific industries for the same reason--including tourism and food and beverage companies--makeres of soft drinks, meat products, cheese etc for picnics and barbecues etc...THOSE are the ones living in the backwards world).
In management/business, engineering, IT work goes on but practically nothing on NEW projects happens. And, because it is vacation time workers are either away on vacation or working overtime covering for vacationers. The poster way up there IS RIGHT. Be patient and see what September brings. If the project is not a big, high-profile one the maintainer is not likely able to commit full-time to it, and if overworked OR on vacation things are on hold. If September rolls by without any response consider it abandoned for your purposes and prepare to take the reigns as maintainer of the forked project--if it is indeed that valuable to you and others you know. Since you work at an academic institution having tha backing/affiliation might work to your credit and help you pick up users from the ancestor project.
Oh yeah, and to ensure interest and adoption make Ubuntu/Debian and Fedora/RedHat (or LSB-compliant) packages available and master the art of lobbying to get those packages in widely used repositories....