Not sure if I am following exactly proper procedures, but we are in need of guidance about how to proceed with TableManager module.

Situation is that while maintainer has not necessarily been silent for 2 weeks, as of yesterday, he has announced that he is abandoning project - see 'Upgrade to D6' thread: http://drupal.org/node/234139#comment-2220180. He indicates that we have offended him and that we should 'write your own Tablemanager module'. He has not provided further commentary in the 24+ hrs since.

This comes of culmination of about 4 weeks dialogue with maintainer, pobster, via on this thread: http://drupal.org/node/599722 and via email. While maintainer was initially very responsive on that thread, dialog has broken down as scope of questions has expanded.

Basic deal is:

- Module has only a .dev version for D6. The .dev version hasn't seen any significant work since Apr 2008 - though a few commits in Aug sponsored by amariotti (http://drupal.org/user/190427). .dev version works in a fashion, but major pieces are not functional. It is used by ~250. D5 version likewise has seen no changes since spring 2008. It is used by ~100.

- Issue queue contains 24 open issues, including 9 open bug reports. Oldest open issue dates to 2006.

- Maintainer announced in March 2008 (on D6 thread and elsewhere) that he would not continue development of .dev version and would instead create new 2.x branch. 2.x branch has since then been mentioned repeatedly with various status updates and whatnot, but nothing has ever been committed to CVS. Maintainer says slow progress due to other commitments and maybe (or maybe not) an issue with code rights/usage permissions due to it having possibly been developed under client contract. Client has, apparently, been using this functioning 2.x version for 12+ months.

- There are no co-maintainers for the module and maintainer appears to have not reached out for one despite the extended period over which he's not been able to commit time himself.

- About 2 weeks ago, myself and amariotti another module user (http://drupal.org/user/190427) agreed to fund revamp of .dev version - to get the 'advertised' features to actually work (e.g., save button that was present in edit screen, but didn't actually save). With prior knowledge of and useful guidance from the maintainer, we posted on 'paid services' forum and found a qualified developer - http://drupal.org/node/611828.

- In first few days of doing the work, developer stated that module would need significant remodeling to get all the .dev features working. Apparently module code was written originally for D4, was never really substantial reworked when moved to D5, and in D6 is currently is not able to support many of the 'advertised' features without a 2.x-type rework. I believe that all these features do work in the D5 version.

- Maintainer was not too receptive when we asked if, instead of limiting our changes to just .dev which might become moot with 2.x release, we could collaborate on a sponsored buildout of the new 2.x branch. Dialog about this can be found bottom of the 'styling cells' thread: http://drupal.org/node/599722. When he hadn't responded to these questions after a few days, we shifted dialog over to the broader thread of D6 upgrade to bring to the attention of wider TM user community -- and that's where he posted his decision to step away.

- At our request, developer has created a roadmap for building out a '2.x' version of the module, but we are a bit stuck to actually move forward with it given current situation.

So basically, we have a mess and need guidance as to best path forward.

Are there additional steps we should take with maintainer to try to resolve situation - or that you should take? Should we take over the TableManager module and build out the 2.x branch ourselves? Should we start a new module which has essentially same functionality, but starts with fresh code base?

As mentioned, myself and amariotti are prepared to sponsor this work, but neither of us is technical enough to be developers or maintainers of the module.

Please note that the TableManager module provides extremely useful functionality that is not available otherwise in the contrib library. We can't get this functionality anywhere else. If you are curious, you can read comparison of HTML tables modules that I wrote here: http://drupal.org/node/619014

What advice do you have?

Comments

silurius’s picture

Subscribing (sorry if this is a breach of protocol - first post to this area of drupal.org).

dave reid’s picture

Status: Active » Closed (won't fix)

Sounds like you'll still need to follow the abandoned project process: http://drupal.org/node/251466. File a support issue in the module and then transfer that issue over to the drupal.org webmasters after two weeks with no maintainer reply or if he/she agrees it should be marked abandoned (and transferred).

john.kenney’s picture

alright, thanks. not the most informative or satisfying answer, but i have done that. http://drupal.org/node/623702

we'll see what he says, if anything.

sounds like this could take a while, i guess our efforts to develop code are delayed for however long it takes to resolve this since such code may or may not have a home at the end of the work. i guess we could take the code private if it came to that.

dave reid’s picture

Status: Closed (won't fix) » Active

I guess I'll leave this as active for now and let some other webmasters comment. We really don't want to forcefully take over modules unless it's a last-case unavoidable scenario. Forking is always an alternative before that point, and again only incase coordination and cooperation don't work.

john.kenney’s picture

right, i can understand being cautious, but if a maintainer can choose to control a module simply by periodically making random posts in his issue queue while doing effectively no concrete work for 18 mths, then something is broken with your process.

if it were me, in addition to the 'abandoned projects' policy which deals only with abject and utter failure, i'd add in a more affirmative policy that sets some sort of guidelines or standards that would be appropriate for module maintainers to achieve - like one obvious guideline might be that "if you can't deliver a stable version of your module within 12 months of a new Drupal version, then you are at risk of forfeiting ownership of your module without notice".

anyway, enough whining about that.

re: forking. i have no idea what 'forking' is, but it sounds like i might like it. would that mean we can start up on another similar module and stick our code in that - if the situation with this module cannot be resolved in a timely fashion? if so, let's get on that post haste.

i appreciate that you've got your 2 week clock thing, but the clock has been ticking for me personally for 1 mth plus to get this functionality into my sites. in hindsight, the easier thing would have been to go private immediately and create a purpose-built piece of code, but then i had no idea that a drupal module could be allowed to exist in such a state of disrepair. lesson for the future, i guess.

pobster’s picture

What is wrong with you? Why are you being such a child? You (or rather Andrew) booked me for coding, which I completed satisfactorily, I tell you the branch 2.x module is not available in CVS because I'm fed up with people posting issues for code which isn't even finished - you can't stop people using dev code on live sites, therefore with drastically changing code I've made the decision to keep it off CVS completely. See you say disrepair, yet it's just unfinished - the entire community has had ample chance to finish this module, yet they don't. Open Source is great when it works but just because you need this module, it doesn't mean that anybody else is interested if they were they're quite welcome to post patches and they'll get committed.

You know very well my 'future plans' for this module, in fact this is from an email thread;

All donations are gladly received but I'd really recommend keeping your money to yourself at the moment at least [referring to previous statement regarding release schedule]

What you're doing is tantamount to cyber bullying and I will not tolerate it. At this precise moment I feel like I would rather delete this module with 9 months of work entirely than have you use any of my code at all. This statement is just excellent;

In first few days of doing the work, [another hired] developer stated that module would need significant remodeling to get all the .dev features working.

So the fact that I'd given you a quote and timescale for completing that very same work means nothing to you? I was prepared to implement your requests yet because it was my birthday and I wasn't prepared to work on it or around it you hired someone else who was incapable of completing that SAME work and it's MY fault?? Again, what is wrong with you??? I'm starting to have had enough of this open source crap, it's more trouble than it's worth. I get two hours maximum on weekdays in the evenings to myself after working, travelling 100 mile roundtrip to work and back, eating dinner and walking the dog - that's why I don't reply all the time, you didn't pay for this software - I don't owe you any immediate responses ever.

edit:
Only just noticed this, "'advertised' features to actually work"... That's classic - has someone charged you for this module? Is that why you're bitter?

Pobster

avpaderno’s picture

Category: support » task
Status: Active » Closed (won't fix)

As per previous comment made from Dave, and for the fact the maintainer of the module replied, I am marking this report as won't fix.

john.kenney’s picture

alright. fine. i'll withdraw and leave you all to it. my apologies for stirring up the situation.

WorldFallz’s picture

@Pobster:

Don't let a couple of rotten apples spoil the bunch. This air of entitlement is not specific to open source-- unfortunately it seems to be a rather common disease in today's world. You do great work-- 99% of drupal users get it and appreciate it. Try to ignore the nonsense from those that don't-- who just seem to be more vocal than those that do. :-(

dave reid’s picture

@Pobster:

This is not cyber bullying, so don't over-dramatize this. We can all be professionals here. He's not trying to rip the module from under you. He's following the set procedure we have here on drupal.org. IF you have a problem with that, let us know.

the entire community has had ample chance to finish this module, yet they don't

I get two hours maximum on weekdays in the evenings to myself after working, travelling 100 mile roundtrip to work and back, eating dinner and walking the dog - that's why I don't reply all the time, you didn't pay for this software - I don't owe you any immediate responses ever.

You're the only maintainer. How is everyone else supposed to 'finish' this module? From what you've said it sounds like you don't have the time to dedicate to this module to get a Drupal 6 finished. Why not add co-maintainers to help you out? And how can people help out if there is no code in CVS? There are obviously people that understand the code and want to help out without forking the module. We do expect some basic form of responsibility when you commit and maintain a module on drupal.org. A lot of us don't have enough time to maintain our modules, so we put them up for adoption or add co-maintainers. It happens all the time.

john.kenney’s picture

in response to #9:

let's be clear about a couple things:

- my tone may leave something to be desired, but myself and another module user have offered to pay 100% the cost of getting this module to work properly on D6 - including, if necessary, rewriting the code base from scratch. only caveat: we need the rework to be done sooner than later - we have jobs to do. pobster has stated that he cannot do the work anytime soon - paid or not paid. so we need to do ourselves - which is fine - except he won't authorize us to pursue the wider scope that appears necessary, let along sharing with us the code he says he has written that already does it all. so we appeared to be at an impasse.

- since we were unsure how to proceed under these circumstances, i posted a msg on forum seeking advice how to handle the situation (stated in the abstract, no specifics, no names). we were instructed by someone who appears to be well respected in the community to post here to give the issue some visibility and get some help. i can point you to that thread if you want. if our tone here has been poor, i take responsibility for that and apologize for it, but we were trying to follow the proper process to get a result that we were unable to get ourselves - at least not in a timeframe that matters.

- if our actions represent a sense of 'entitlement' with regards to open source, then you're right, i don't have much clue how open source is supposed to work. to me, a module maintainer who tightly controls his module, fails to make improvements to it for extremely long periods of time, doesn't publish his code, cites possible ownership issues with his code, and who rebuffs people who want to help, including ones who are putting money on the table, now that sounds more like somebody who isn't with the open source program.

- in terms of next steps, we remain committed to building out a working TableManager module (or it's equivalent) sooner rather than later - we simply need the functionality. if somebody on webmaster's wants to approve us to do that under another module name, a 'fork' I guess is the term, then that'd be great. if there is a way to work things out with pobster, then we'd be happy to do under current module. otherwise, we'll take the work private and leave it at that.

pobster’s picture

Status: Closed (won't fix) » Closed (fixed)

What is wrong with you??? I never said that I couldn't do the work - I said it was my birthday and that I had plans??? It was my birthday, what did you expect??? I was perfectly willing to do the coding the following weekend.

And just because I don't get much free time during the week doesn't mean that I have no time at all, I do all my coding at weekends. I've no idea why I have to justify myself at all but seeing as you all seem to have ganged up here I need to say something at least. I have roughly 20 projects on the go at the moment and Tablemanager is not top of the list, that's all... I haven't rebuffed anyone, you hired a guy to do some coding and I'll use what he wrote once I've fixed it, it breaks three things opposed to the one thing it's supposed to fix... But on the plus side, it has some good ideas with only one piece of oddness.

So... You think I should add co-maintainers? Like the Drupal project does? No... Wait it doesn't... And with damn good reason too, it's just as time consuming vetting other peoples code and when every Tom, Dick and Harry has direct access to CVS you get *really* shoddy code, just because you choose to do this doesn't mean it's the way it should be done. I've lost count of the amount of times I've completely reinstalled XML sitemap because the upgrade path didn't work (that's not a pop btw, it's just an example of a pet hate of mine - don't feel you have to defend it). Anyways, my point with this is that anyone can check a module out of CVS, work on it, post an issue and supply a patch. No co-maintainer necessary, no problem.

I'm not interested in this becoming a discussion so please don't bother replying, I likely won't bother reading any more of this thread.

Pobster

dave reid’s picture

Status: Closed (fixed) » Closed (won't fix)

No need to change the status to closed (From http://drupal.org/node/156119: "This status is used exclusively by the Project Engine to close "fixed" automatically after two weeks of inactivity. You should not need to set this status yourself")

Ok, sounds like you are still wanting to maintain, and the best way for people to contribute is to submit patches. That's always a good start. So unless the module has been identified as abandoned by the set drupal.org process, we can't force you to do anything. So it's ultimately up to you and how you want to handle maintaining your module. We'll leave it at that.

pobster’s picture

Apologies I didn't even notice this thread isn't under Tablemanagers issue queue. No worries, this is just getting me down as there's so many lies floating around. If it's not bullying then it's certainly defamation...

It appears he may or may not choose to commit the patch that comes out of the effort and he continues to be vague about when/if there will be an official, stable D6 release based on our improvements.

That statement comes out of pure fantasy, I swear the guy has dreamt most of what's been said. Anyways, enough is enough - thanks for the audience.

Pobster

john.kenney’s picture

didn't have to do with a single day of unavailability, pobster quoted on http://drupal.org/node/599722#comment-2209146 from oct 30:

"It's not as easy as that, as I mentioned above - I'm going to need to check with our works legal department, tbh it's the main root of why I'm so easy convinced to drag my heels over developing 2.x - I can't just release code which has been used on clients projects, it's obviously not an easy position to be in. I'd forget about it for the time being but if you're really interested - there's many details about what's new in other issue queues."

it seems best if we go our separate ways.

pobster’s picture

Well I apologise that does sound far worse than it is, I've already quantified that statement with you though in that I only need to ask out of professional courtesy and even then I could refactor the code anyway. It's a little out of context posted like that.

Pobster

john.kenney’s picture

participants in this thread might be interested in these related new threads: http://drupal.org/node/772790, http://drupal.org/node/772792

Project: Drupal.org site moderators » Drupal.org project ownership
Component: Project ownership » Ownership transfer