×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Contributing To a Project With a Reclusive Maintainer?

Soulskill posted more than 4 years ago | from the pulling-a-davis dept.

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

162 comments

Fork it! (5, Funny)

Anonymous Coward | more than 4 years ago | (#28994747)

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.

Welcome to the world of OSS (5, Insightful)

Anonymous Coward | more than 4 years ago | (#28994885)

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.

Re:Welcome to the world of OSS (5, Insightful)

characterZer0 (138196) | more than 4 years ago | (#28995245)

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.

Re:Welcome to the world of OSS (2, Insightful)

HomelessInLaJolla (1026842) | more than 4 years ago | (#28996733)

If it is important enough then it may be written again. If it is not important enough then a stale sf.net page provides testimony to how unimportant it was.

Re:Welcome to the world of OSS (2, Insightful)

buchner.johannes (1139593) | more than 4 years ago | (#28995797)

I prefer stale sf projects to scientific papers that say they modified X (e.g. ns), but never show the code.

Re:Fork it! (0)

Anonymous Coward | more than 4 years ago | (#28994941)

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.

blackjack and hookers???

I would have said a small beowulf cluster with a few thousand nodes....u don't belong on /.

Re:Fork it! (1, Insightful)

Anonymous Coward | more than 4 years ago | (#28995169)

Not realising a simple Futurama reference causes you to indeed not belong on /.

Re:Fork it! (1, Insightful)

Anonymous Coward | more than 4 years ago | (#28995847)

I would have said Natalie Portman and hot grits.

Get off my lawn.

Re:Fork it! (4, Insightful)

petermgreen (876956) | more than 4 years ago | (#28995107)

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.

Re:Fork it! (4, Insightful)

wigaloo (897600) | more than 4 years ago | (#28995513)

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.

Re:Fork it! (-1, Troll)

Anonymous Coward | more than 4 years ago | (#28995719)

Insightful?!? I never take vacations, and not everybody has family or friends. Seriously, dude, what the fuck?

Re:Fork it! (1)

houstonbofh (602064) | more than 4 years ago | (#28996217)

Insightful?!? I never take vacations, and not everybody has family or friends. Seriously, dude, what the fuck?

And you run all the Linux projects? Man! You are a GOD!

Re:Fork it! (0)

Anonymous Coward | more than 4 years ago | (#28995949)

What kind of bizarre world do you live in? August is only a big vacation month in France and teachers' unions.

Re:Fork it! (1)

liquidsunshine (1312821) | more than 4 years ago | (#28996079)

Or University, where many programmers are. And since a lot of people have children, August is a popular time to take work leave to go somewhere with them.

Re:Fork it! (2, Funny)

Anonymous Coward | more than 4 years ago | (#28996453)

If by France you mean almost all of Europe, Australia, South Africa and most of North Africa, as well as significant parts of Asia and if by teacher's unions you also mean ALL of academia globally, you got that exactly right. We're only talking about a paltry 2 billion people give or take a few hundred million. What kind of world do you live in?

Re:Fork it! (1)

Ritchie70 (860516) | more than 4 years ago | (#28996735)

France apparently also includes portions of North America as well.

Only my gut feel, but I suspect August is second only to December in percentage of people on vacation at my work place.

Re:Fork it! - not funny (2, Interesting)

petes_PoV (912422) | more than 4 years ago | (#28995123)

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.

Re:Fork it! - not funny (5, Funny)

Provocateur (133110) | more than 4 years ago | (#28995165)

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

Yes and ... (5, Funny)

OeLeWaPpErKe (412765) | more than 4 years ago | (#28995677)

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

Re:Yes and ... (-1, Troll)

Anonymous Coward | more than 4 years ago | (#28996313)

Agreed, except for the orphans part.

Re:Fork it! (3, Informative)

Directrix1 (157787) | more than 4 years ago | (#28996099)

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?

panties STINK! (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#28994749)

Panties Stink!
They really, really stink!
Sometimes they're red, sometimes they're green,
Sometimes they're white or black or pink
Sometimes they're satin, sometimes they're lace
Sometimes they're cotton and soak up stains
But at the end of the day, it really makes you think
Wooooooo-wheeeee! Panties stink!

Sometimes they're on the bathroom floor
Your girlfriend- what a whore!
Sometimes they're warm and wet and raw
From beneath the skirt of your mother-in-law
Brownish stains from daily wear
A gusset full of pubic hair
Just make sure your nose is ready
For the tang of a sweat-soaked wedgie
In your hand a pair of drawers
With a funky feminine discharge
Give your nose a rest, fix yourself a drink
cause wooooooo-wheeeeeee! panties stink!

Extensions and black holes (3, Insightful)

BadAnalogyGuy (945258) | more than 4 years ago | (#28994757)

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.

Re:Extensions and black holes (-1, Troll)

Anonymous Coward | more than 4 years ago | (#28995119)

Yes, sometimes a strap-on is precisely what is needed to fill a black hole.

There's no need for racism sir!

Re:Extensions and black holes (3, Insightful)

WillDraven (760005) | more than 4 years ago | (#28995947)

What is the specific project you're fixing up?

Not to mention you're asking slashdot. Somebody here could know the guy who maintains it, or at least know somebody who mentioned to them that he got hit by a bus.

Try sending to some distribution (4, Informative)

Anonymous Coward | more than 4 years ago | (#28994759)

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)

Money makes the world go round (5, Interesting)

Bananenrepublik (49759) | more than 4 years ago | (#28994761)

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.

Never worked for me in the past (4, Interesting)

Sun (104778) | more than 4 years ago | (#28995279)

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:Never worked for me in the past (1)

houstonbofh (602064) | more than 4 years ago | (#28996245)

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.....

I have done this, and it has worked exactly 50% of the time. OK, I did it twice, and it worked once. :) But it really worked well that once!

Re:Never worked for me in the past (1)

dcollins (135727) | more than 4 years ago | (#28996275)

That's interesting and useful information and I'm glad that you presented it here.

"The theory is solid..."

Well, apparently it's actually not -- more like it comfortably feeds into a lot of Slashdot free-market superstitions.

Re:Never worked for me in the past (2, Interesting)

Sun (104778) | more than 4 years ago | (#28996299)

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.

Re:Never worked for me in the past (1)

Jamie Lokier (104820) | more than 4 years ago | (#28996481)

That's interesting and good to know your anecdote; thank you.

I have some ideas on why it may never have worked.

Offering someone money to incorporate your changes is akin to offering short-term paid work. This is because they will have to do some work - and because when they accept the money, they are duty bound to do what you've asked.

Most people do not work as freelancers, and cannot take new short-term jobs easily. They also do not know how to respond to money offers as a freelancer would.

Remember, most non-commercial open source is written by people in their spare time, so they aren't expecting to be offered money and aren't used to it.

Just like other unsolicited job offers, they're quite likely to be working for someone else full-time, or busy with other things. They may have to say no even if they like your offer, or they might simply not be interested.

They may think you require more of their time then you do, and they may not be sure if it would cause problems with their employer to accept money for work from someone else at the same time.

As with all unsolicited offers of work, if you want to be successful that's more likely if you offer enough money to offset the inconveniences and problems of taking you up on it, including imaginary problems.

For some who already does not have time to maintain a project they care about, that means offering more than the commercial rate for the amount of work you think is involved.

I'm curious, what sort of amounts have you offered? I have offered money too, but it has always been "feel-good" amounts to express gratitude afterwards, and did not require anything to be done; it was never enough to pay seriously for work.

Re:Never worked for me in the past (1)

Sun (104778) | more than 4 years ago | (#28996591)

I'm curious, what sort of amounts have you offered? I have offered money too, but it has always been "feel-good" amounts to express gratitude afterwards, and did not require anything to be done; it was never enough to pay seriously for work.

I don't recall ever getting to the point where amounts were even discussed. Most often I was not offering to pay to include a patch I already made, but to have the bug resolved (and, in one case, I was offering money to either get a redistribution license for a freeware+source, or have the writer accept enough money to just open source it).

In all cases, I never got a reply.

I think the relicense case is of particular interest. I needed, for the course of a project, to use chntpw. At the time, it was a freeware+source non-free software. I emailed the author saying "either sell me a royalty free license, or tell me how much money it would take to make you open source the tool". I never got a reply. A few years later, the author relicensed the tool as BSD. I have no explanation for this.

contact the package maintainer instead (5, Informative)

quitte (1098453) | more than 4 years ago | (#28994763)

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.

Just fork it (5, Insightful)

Anonymous Coward | more than 4 years ago | (#28994783)

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.

Re:Just fork it (2, Informative)

Chemisor (97276) | more than 4 years ago | (#28995091)

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:Just fork it (4, Interesting)

TheRaven64 (641858) | more than 4 years ago | (#28995309)

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.

Re:Just fork it (2, Insightful)

Thad Zurich (1376269) | more than 4 years ago | (#28995883)

Am I the only one that finds the statements "new to programming in C", "asked to extend an open source authentication module", and "testing has been done and it works as designed" to be utterly incompatible? Come to think of it, "authentication module" should be incompatible with "C" in any context, to say nothing of "new to programming" and "authentication module".

open source = fail (-1, Troll)

Anonymous Coward | more than 4 years ago | (#28994785)

Open source is a messy failure. Face it!

Re:open source = fail (1, Funny)

Anonymous Coward | more than 4 years ago | (#28995343)

I guess you won't be coming back to slashdot then since it's running on messed-up failing software...

Re:open source = fail (1)

DocHoncho (1198543) | more than 4 years ago | (#28995975)

... 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.

Publish patches (5, Informative)

KarlH420 (532043) | more than 4 years ago | (#28994803)

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.

Re:Publish patches (4, Insightful)

TheRaven64 (641858) | more than 4 years ago | (#28994931)

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.

Private copy is not a fork (2, Insightful)

b4dc0d3r (1268512) | more than 4 years ago | (#28995613)

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.

It's OSS. Do what you like. (2, Informative)

Anonymous Coward | more than 4 years ago | (#28994813)

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.

What is your definition of "robust"? (4, Interesting)

BadAnalogyGuy (945258) | more than 4 years ago | (#28994823)

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.

MTTF (3, Insightful)

codeguy007 (179016) | more than 4 years ago | (#28996253)

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.

Re:MTTF (1)

Abcd1234 (188840) | more than 4 years ago | (#28996695)

Indeed. Last I checked, software didn't suffer from random bitrot (well, save for cosmic rays and failing disks). It either works, or it doesn't.

Re:What is your definition of "robust"? (1)

ac666 (535743) | more than 4 years ago | (#28996341)

While trying to be a little less mean than your other respondent - the tone of your reply is rather unfortunate. The OP question indicates that they did a fair (unusual?) amount of due diligence for a first-time contributor. How about giving them some credit for that BEFORE you shift into curmudgeon mode - and not assuming in advance that the answers to your questions will be negative?

This wasn't something to do with the ... (5, Funny)

kevingolding2001 (590321) | more than 4 years ago | (#28994843)

... tty layer was it?

Re:This wasn't something to do with the ... (0)

Anonymous Coward | more than 4 years ago | (#28995097)

nah it could be to do with reiserfs though

black hole (2, Interesting)

speedtux (1307149) | more than 4 years ago | (#28994911)

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:black hole (2, Insightful)

Aladrin (926209) | more than 4 years ago | (#28995041)

And how long did he wait? Maybe the maintainer is on a vacation. People have lives, and he's under no obligation to answer immediately.

Re:black hole (1)

gbjbaanb (229885) | more than 4 years ago | (#28995581)

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.

I like this, Sourceforge should implement it immediately!

I also think there are a lot of OSS projects out there that that have fallen into disuse (I don't refer to the popular ones), perhaps SF should have a policy of only accepting projects that have 2 owners, like a chairman and secretary for a public company, so there is always someone who can tell you to sod off when you suggest a patch. (and if you have no friends, you should be able to pick from a list of 'non-executive' volunteers).

Fork it. (3, Informative)

imbaczek (690596) | more than 4 years ago | (#28994953)

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 don't need no stinkin patches. (-1, Offtopic)

jety2k (118024) | more than 4 years ago | (#28994961)

Could be that your "patch" is so trivial that it has been placed in a low priority queue and the maintainers will get to it when they have time! Duh!!! Get over yourself and be patient.

Yes, it happend to us (4, Informative)

Sun (104778) | more than 4 years ago | (#28995023)

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:Yes, it happend to us (1)

dannycim (442761) | more than 4 years ago | (#28995105)

Off-topically I have to say that "Shachar Shemesh" totally rolls off the tongue. :) Cool name. Oh, and there's a misspelling on your front page; it's "Know-how", not "know how".

Off topic: What's to a name (1)

Sun (104778) | more than 4 years ago | (#28995259)

Fixed the spelling (punctuation, actually) mistake. Thanks.

Regarding the name, I'll quote from my old home page [shemesh.biz]. 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:

Once upon a time, I had a simple, very easy to understand, name. My given name had three letters, as well as my family name. It was clear to anyone hearing my name how to spell it, and to anyone seeing my name written how to pronounce it.

Without anything actually happening to me, this all changed, suddenly and ruthlessly, one day towards the end of 1991. The trigger of the change was a (now almost dead) utility called "Internet Relay Chat" - IRC. The cause of the change was most of the world's inability to speak Hebrew. All of a sudden I found that both my given and my family name were seven letters long, and no-one knew how to spell either one, let alone pronounce them.

Trying to find acceptable alternatives, I turned to the fact that most names given in Hebrew have a meaning. In my case, "Shachar" means "dawn", "Shemesh" means "sun". Since Dawn is a female name, I went with "sun".

When the domain buying craze started, I found out that sun.com [sun.com] was already taken. While I had the fleeting idea of suing the sneaky bastards, I decided to let the case drop.

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

Re:Off topic: What's to a name (1, Interesting)

Anonymous Coward | more than 4 years ago | (#28995411)

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.

Re:Yes, it happend to us (0)

turbidostato (878842) | more than 4 years ago | (#28996139)

"We ended up forking - mawstats."

What for?

"The extension was part of a project done for a client of ours [...] we did everything we could to contact upstream, and it was either fork or keep things to ourselves."

So your client needs where already fulfilled and the upstream maintainer was MIA; so there wouldn't be no new upstream versions, so there wouldn't be nothing to repatch. Therefore, what was the problem with keeping things to yourselves or just publishing the patch on the old project devel list and that's all?

"If you have no choice, then you have no choice."

Unless you expect further conflicting development from upstream there's no need to fork (of course you still might *want* to fork, but then that's your choice, quite different to "there was no choice"): there would be only clean patches to apply or nothing to patch at all.

Death. (3, Insightful)

MMC Monster (602931) | more than 4 years ago | (#28995069)

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?

Re:Death. (0)

Anonymous Coward | more than 4 years ago | (#28995099)

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

Bullshit.

certainly fork the code. when can a new maintainer take the trademark/name of the old project

It doesn't matter! A Linux system is made up of a zillion little (and big) parts, with many of them varying by distro. A new replacement part coming along happens all the time. And if it's 100% backwards compatible, like the subject of this post seems to be, it's trivial for the distro maintainers to swap components. The only relevant issue is whether someone is willing to maintain the new project.

Re:Death. (2, Informative)

Lumpy (12016) | more than 4 years ago | (#28995443)

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.

Re:Death. (2, Insightful)

Jorgensen (313325) | more than 4 years ago | (#28995463)

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

Sorry - this is too far from the truth to be caused by mere ignorance...

Obviously, FOSS cannot revive the maintainer (but neither can proprietary software projects). But in FOSS projects, the death of a maintainer will not (by itself) force the death of the project. The only thing that kills FOSS projects is lack of interest.

Anybody can step up to the plate and take on the role of maintainer, simply because the code is still available. If nobody does, then the project is likely to die. But that will only happen if nobody is interested enough to help.

Re:Death. (1)

mrmeval (662166) | more than 4 years ago | (#28995635)

Or they wrote the program using some dos based C compiler that links to a several proprietary libraries which have no documentation. The libraries have no upgrade path as the companies no longer exist. The C compiler is I think an MS one with an unknown addon package.

Of course the company had a down turn and let the person go and 10 years later they need the code 'fixed' to work on windows. I'm happy to say it won't be done by me. :)

Re:Death. (4, Interesting)

adamkennedy (121032) | more than 4 years ago | (#28995935)

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

Just post the project name here. (0)

Anonymous Coward | more than 4 years ago | (#28995073)

Maybe the maintainer does not read his e-mails while he is on holiday. But who would go on holidays without reading /. daily...

Holidays (5, Funny)

Anonymous Coward | more than 4 years ago | (#28995075)

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

Aye (0)

Anonymous Coward | more than 4 years ago | (#28995117)

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

My project, my blackhole. (3, Insightful)

inflex (123318) | more than 4 years ago | (#28995177)

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? :)

Re:My project, my blackhole. (0)

Anonymous Coward | more than 4 years ago | (#28995303)

or you find that life outside of OpenSource keeps dragging you away from getting around to applying patches

Like the fact that you have to pay the bills: health and car insurance, food, rent or house payments, etc... and OS projects are the worst ways to actually make a living - unless you're one of the very very lucky few like Linus who end up with 7 figure jobs because of it.

Of course, if you're living in your parents basement or living in a country that has legislated 6 or more weeks of vacation and 35 hour work weeks, then you'd have plenty of time to give your labors away for free - and still be able to make a living.

The F/OSS development lifestyle only works in pseudo-socialist countries.

Re:My project, my blackhole. (1)

dolmen.fr (583400) | more than 4 years ago | (#28995395)

In France we have only 5 weeks of holidays. We work 35 hours/week (which when you effectively work 39 hours/week gives you 10 more days of holidays).
But it's still not enough to contribute more to free software: vacation is time for going away from your keyboard. The exception being to bring your keyboard with you to go abroad to a free software conference such as YAPC::EU::2009.

Re:My project, my blackhole. (1)

theSpitzer (1504349) | more than 4 years ago | (#28995987)

5 weeks! Damn, and your complaining? Typical in Canada is 4% (2 weeks). Personally I have 3 and I dont complain.

+1 so true (1)

Jamie Lokier (104820) | more than 4 years ago | (#28996647)

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.

Similar Story (3, Interesting)

markus_baertschi (259069) | more than 4 years ago | (#28995233)

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

Federal pound-me-in-the-ass prison (0)

Anonymous Coward | more than 4 years ago | (#28995325)

It's hard to not be reclusive when behind bars at San Quentin.

Re:Federal pound-me-in-the-ass prison (0)

Anonymous Coward | more than 4 years ago | (#28995517)

Maybe the maintainer is Hans Reiser?

publish it on sf or github or freshmeat (1)

kikito (971480) | more than 4 years ago | (#28995547)

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.

This is why I no longer open-source my projects (4, Interesting)

ugen (93902) | more than 4 years ago | (#28995841)

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:This is why I no longer open-source my projects (2, Interesting)

Dhalka226 (559740) | more than 4 years ago | (#28996567)

You're certainly free to distribute your software however you please, but if these were your feelings about open source software --

I used to open-source everything I do. No more. [. . .] 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

-- 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 (3, Insightful)

Abcd1234 (188840) | more than 4 years ago | (#28996679)

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.

Actually, I think it goes deeper than that.

Most people don't *want* to fork projects. Your average contributor is a career developer who's probably being paid to do something else entirely, and only contributed to the project because they needed some functionality to get their job done. Alternatively, they're hobbyists, in which case taking on the responsibility of maintaining a fork isn't something most people are interested in.

Instead, the reason forks happen is because the maintainer is, for some reason, hostile to the wishes of some not-insubstantial portion of their user base. In this particular case, it appears the OP is actively *annoyed* by people requesting features. Well, big surprise that, in such a situation, people are likely to fork your codebase: given the option between maintaining your own fork or dealing with a hostile maintainer, forking is obviously the best solution. And so the OP, rather than, say, being less hostile to and more cooperative with his user base, chose to simply take his ball and go home.

Fundamentally, it's an attitude problem: some people see software development, and OSS in general, as a collaborative process, and enjoy working with others, accepting contributions, etc. Others, however, see users and potential contributors as a nuisance and something to avoid. Big surprise if the latter group choose to obviate OSS in favour of a closed development model.

Re:This is why I no longer open-source my projects (4, Interesting)

Abcd1234 (188840) | more than 4 years ago | (#28996637)

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.

Re:This is why I no longer open-source my projects (2, Interesting)

uid7306m (830787) | more than 4 years ago | (#28996685)

            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.

Publish patches on your own, (0)

Anonymous Coward | more than 4 years ago | (#28995869)

and then learn to stop capitalizing university automatically.

Would you expect someone to talk about working at a Company?

Provide your work as patches and link to a tarball (1)

Thunderbear (4257) | more than 4 years ago | (#28995873)

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.

Be Professional, Patient, Assertive (5, Informative)

desertcrevasse (619379) | more than 4 years ago | (#28995903)

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

This is a big problem in the Python world. (4, Interesting)

Animats (122034) | more than 4 years ago | (#28996317)

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.

we need to be fair among gender even in IT (0)

godrik (1287354) | more than 4 years ago | (#28996359)

Everybody is talking about forking it. T be politically correct and fair among genders, I suggest we spoon it instead.

Organizational standards in FOSS projects (1)

cenc (1310167) | more than 4 years ago | (#28996405)

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.

The reclusive maintainer (3, Interesting)

br00tus (528477) | more than 4 years ago | (#28996649)

I once wrote a patch for a program on Sourceforge that was only a few lines but had taken weeks to figure out, and it definitely improved the package. I wouldn't call the maintainer reclusive, he was more like a cuckoo clock who would show up once a year, work like crazy on the program, then disappear again. After I wrote the patch he disappeared. A few months later, I was busy myself and forgot about it. Two and a half years later I started getting e-mails from his projects mailing list again where he was saying he was putting out the new version. He had already updated a bunch of files in the CVS, so I redid my patch against the latest CVS and made noise about my patch again. Well, he included most of it in his next release. Until then, it was sitting in the patches part of Sourceforge for anyone who would be very serious about the program to see.

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.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...