I was chatting to Joachim at DrupalCon about module writing and I was telling him that at work we often produce custom module code for specific sites but find it very hard to set aside enough time to polish them into proper modules to upload to Drupal.org. He suggested some kind of module 'Badlands' where module code could be dumped and tagged and intrepid developers could search for and potentially make use of code from these modules.

I think there are many companies commercially using Drupal who would like to give something back but don't have the time/money to do so properly through module maintenance on Drupal.org. This concept could be a chance to get more code out there, kind of like snippets I guess, but more module based. I know some companies do this through their blogs but I thought that something more official might make more sense. Seeing as its Drupal.org redevelopment time I thought I'd offer this concept up for your evaluation.

What do you think? Is it something that would be of use to the community or would it foster bad habits (i.e. undeveloped and unfinished code)?

Currently there is a sandbox in CVS but its only possible to get an account by first uploading a module. This creates a barrier to contributing code. This 'badlands' idea could allow more module code to be released into the wild and with intelligent use of meta tags it could become an excellent resource for other developers.

Any ideas and discussion most welcome.

Comments

greggles’s picture

There is the sandbox: http://cvs.drupal.org/viewvc.py/drupal/contributions/sandbox/

The trick is that you want it to be visible enough that other developers will find it and maybe polish it off, but not visible enough that people will really start using it.

joachim’s picture

Subscribing :)

Meeting people at the Drupal events in London made me realize there is a huge mass of Drupal code that never sees the light of day. Hence this idea :)

(The best ideas are thought of over lunch!)

Dave Reid’s picture

I don't think it is absolutely required to have a new module ready before you apply for a CVS account, but it would be required to have a CVS account to contribute to your sandbox. Many developers have their own sandbox (link in #1). Also see http://drupal.org/node/59 for the guidelines for applying for a CVS account.

Gerhard Killesreiter’s picture

Status: Active » Closed (won't fix)

We don't want even more bad code...

dman’s picture

noo.
I know that all decent site developments do quickly need a small repository of custom code - but they are custom because they are specific to unique requirements and unique setups.
The best practice may be to create mini-modules (it's easy) but to drop them all in a pile with no documentation, no ownership, no maintainance, is a losing proposition.
Looking at unfinished, worst-practice code without context is not a way to learn re-use.

In the middle, we can drop mini-modules into the snippets pages as-is-where-is. caveat emptor.

But I'd suggest that any module worth keeping or learning from is worth its own identity.

kbahey’s picture

There is a discussion here on this. http://groups.drupal.org/node/15279

See my suggestion here: we can have a project called "Unmaintained contributions" and people attach .zip or tar.gz to issues to that. See here http://groups.drupal.org/node/15279#comment-51577

dman’s picture

I saw that discussion, and inasmuch as the intention is to find a way to reduce the barrier to entry that CVS is percieved to be, there is some hope for it.

But ignoring the very problem that CVS was invented to solve is not a solution.

"Doing things the right way is hard - lets give up and not do the right thing" :-(
"Doing things the right way is hard - lets find ways to make it easier to do it right" :-)

... if that means coming up with a magic system that auto-commits peoples uploads into CVS for them, that would be cool. Surely it's been done before. We have web-based repository checkouts, why not commits?

There's no real reason (apart from time and/or money) why someone couldn't just upload a copy of the file they changed into the issue queue and have a system generate the patch that maintainers are so picky about! ... just a random thought. Anyone want a project?

I know it's not as simple as all that, but it's not impossible either.

joachim’s picture

> The best practice may be to create mini-modules (it's easy) but to drop them all in a pile with no documentation, no ownership, no maintainance, is a losing proposition.

Sure.
But the current situation is that developers everywhere are reinventing the same wheels because they don't know that someone else has already written code for nearly the same thing.

catch’s picture

Thing is though, developers already re-invent the wheel when there are published projects availalble for download - some with decent documentation and user base already - either because they couldn't be bothered to research, or they couldn't be bothered to supply patches to an existing project rather than write their own. If the 'badlands' was to move so many of these poorly written, insecure, duplicating modules to some kind of holding bay, then that'd be great, but encouraging people to submit even more doesn't deal with the root problem imo.

greggles’s picture

I agree with catch and killes and...

The sandbox has been a reasonable place for things like this in the past. But if you are looking for a higher visibility place then that's just a bad idea.

Instead of disagreeing on this point, a better idea would be to make sure people are aware of the Module Documentation Recommendations so that it is easier for them to properly document their modules so they can be released more fully.

joachim’s picture

I don't think the problem is lack of documentation.
In my personal experience, the code I write for a client is sound, well-documented, but not generic: I hard-code settings, don't create an admin interface, and so on, because there isn't time and many aspects of the client's site won't need to change.
If another coder on another project used the time they would have spent rewriting my code to add those elements, you'd get a pretty sound module.

dww’s picture

@joachim: Then make a project node for it, don't create any release nodes, assign the project to the Abandoned Modules user, and clearly explain in the project description what's wrong with the current code and what it would take for someone to turn it into something generally useful to the community. See http://lists-new.drupal.org/pipermail/development/2006-December/021316.html for a more thorough explanation of why this is a good idea.

dman’s picture

That was a really informative post, thanks!
I think that the combination of snippets, sandboxes, and a few other existing catch-all projects like http://drupal.org/project/tweakbox http://drupal.org/project/util are enough.
If it's not worth describing enough to make a snippet page about, it's not worth keeping.

Anything else can go to pastebin. If you learn anything from what you find there, more power to you.

dww’s picture

@dman: Thanks. ;) I just created #315676: Getting involved: update project maintainer practices with wisdom from the devel list? about harvesting goodness from there for the handbooks...

joachim’s picture

I don't know who set this up: http://groups.drupal.org/wastelands

dman’s picture

Amazon’s picture

Assigned: Unassigned » Amazon
Status: Closed (won't fix) » Active

Tmanc, Joachim don't give up. I think the idea of a Drupal module scratchpad is a great one. In particular, if you could add a bunch of meta data, search through the code, and be able to flag the code as to it's state.

Everything we can do to ease the on ramp to making your first contribution to the Drupal project is a good idea. Sure the security team is inundated with unmaintained code, but this might give us a nice place to push projects down to.

Let's keep brainstorming about how to to reduce the infrastructure requirements and how to adequately inform people that this code is unmaintained.

I'll take on this project, and help keep the discussion alive. I can't promise anything on the implementation, but it's an important idea.

Kieran

killes@www.drop.org’s picture

Project: Drupal.org infrastructure » Drupal.org site moderators
Component: Other » Redesign

I fully disagree with Kieran, of course. However, if you want to discuss this (so that I can shoot it down later) please do so as part of the redesign discussion, since it will certainly not be implemented with the current way d.o operates.

Alternatively, feel free to register drupal-code-that-nonody-will-ever-use.com...

catch’s picture

Everything we can do to ease the on ramp to making your first contribution to the Drupal project is a good idea.

Contributing broken, security-hole-ridden, undocumented modules that duplicate the functionality of well-maintained, secure, documented modules does the Drupal community a disservice in many cases. If a module doesn't merit that description, then there would be no need to post it in the badlands.

I'd much rather see efforts go into making it easier for people to get involved submitting, reviewing and testing patches for existing projects. We desperately need more people doing this, especially in contrib,but for some reason many people apply for CVS accounts and post modules up serially instead. Getting past the idea that contributing code to Drupal (much less contributing in general) is about posting up modules to the exclusion of everything else is a major barrier to useful participation for many potential contributors.

greggles’s picture

I actually find myself somewhat OK with this idea. I've long wanted a "badlands" for bad modules and bad maintainers. People who don't follow the security guidelines and who make security fixes without following the proper process could have their modules demoted to the badlands with a suitable warning attached to those pages.

And then we could say "modules in the badland are outside of the watchful eyes of the Drupal security team. If you run these you are on your own. The security team will not send announcements related to modules in the badlands."

It would reduce the security team workload and, for maintainers who prefer to be "in control" (see discussion from dev mailing list in January) it provides them the perfect environment.

catch’s picture

If we can demote modules to there, then I'd be OK with it too - since that would actually reduce the clutter instead of adding to it.

EclipseGc’s picture

So, here's the deal. This idea was first (that I know of) conceived at Drupalcon Boston. I was speaking with some members of one of the larger corporate Drupal companies, and (as has happened many times with more "corporate" developers) we all identified that we have code we'd like to offload, but don't have the time to do so in the current Drupal environment (at least, not if we have any hope of seeing it actually come to fruition). Now, this company far better about polishing off modules and committing them than we (The Worx Company) are, but Joachim's description is spot on. In most cases, we actually understand Drupal pretty well, our code won't be perfect, but it's a good kernel, and if properly filed in a place people could find it, it might get developed into a full fledged module.

Case in point:
We started a project about 6 or 7 months ago. At that time we had a need to actually SELL node creation. Ubercart had no way to practically do this at the time, and we'd abandoned ecommerce months before. We developed up our own site specific version of a module that could do exactly that. Now, had I had this particular venue of options open to me, we'd have taken that code, documented what it was for, and plopped it into the bad/wastelands. Then when Ryan Szrama needed the same sort of module for the Do it With Drupal seminar site, (which is what I believe uc_node_checkout was built for) he'd have had a good working kernel to build from instead of starting from scratch and essentially rewriting what we had done already. This is just one example that we've run into in the last year, most of them ubercart based (did the same thing with selling a role subscription).

Now, I know there are a million different ways this code COULD have been committed to satisfy existing Drupal standards, however... what we're saying here is that 1.) that's not very visible (to those we'd like to be visible to) and 2.) that's actually sort of a liability for d.o in general (in the support or lack-there-of sense).

What I would propose is this:

1.) If you're interested in actually solving this problem, then join the wastelands group and let's take this discussion there.
2.) Drupal.org has a ton of stuff on it already. No need to confuse by adding more. Let's put together another site that's entire purpose is tracking, and helping developers improve this sort of code. (whether that's a completely separate site, or a wastelands.drupal.org I don't really care, oh and separate CVS)
3.) I've committed to making this happen one way or another. That doesn't mean it'll be fast, but with it coming up in front of me at two Drupalcons now, I really do believe in this project, and I think there are probably some really cool implementations we could put together here that would help with tracking, and improving, and it would be a real success story for the community in general if we came up with a good way of doing this.

That's my story and I'm sticking to it. :-) I've had discussions with more than a few corporate developers, and I really feel that done properly this could turn out really nicely. (without any extra overhead for the existing d.o projects, or the corresponding CVS or the respective maintainers)

PS: I'm not against Greggle's approach, however I think that then lumps unmaintained crap code with the kernels of potentially good code that people now have to sift through. Of course the opposite side of that coin is that if ANYONE can contribute to the wasteland, then it would eventually fall into the same state, so...

Wolfflow’s picture

+1 #20 really good feedback. "Give always place to different thinking" (I don't know who wrote that before!) ;-)

apaderno’s picture

What should the status of this report be? One year passed from the last comment.

patcon’s picture

Really like this idea! Subscribing.

apaderno’s picture

I actually don't think it's a good idea to have something that can be done in the sandbox. If it's code that is not good enough to be a project, then it can be placed in the sandbox.

patcon’s picture

@7

Interesting... :)

But meh -- having read through it all now, it has a group now (http://groups.drupal.org/wastelands), so it seems closed.

greggles’s picture

Status: Active » Fixed

We now have sandboxes, which fulfills this goal.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.