The Problem

We lack a clear and inviting path from discovering Drupal and learning how to use it to becoming an active and productive contributor. As a result, our most active developers are plagued by the support demands of intermediate users who have outgrown the Drupal.org forums and don't know where to go. This effect is compounded both by our failure to attract and assimilate new highly qualified support-givers, and the myriad bad behaviors that newbies are learning in "newbie ghettos" such as the forums -- behaviors that make it difficult-to-impossible to adequately support them and bring them into the wider Drupal community.

The Solution

• Phase out the Drupal.org forums in favor of a more straightforward Q&A format resource.
• Treat posts that resource as not just the answering of this question here and now, but building a useful searchable reference into the future. Be brutal in eliminating off-topic chatter and duplication (but as kind as possible in explaining why a question was closed) ala StackExchange.
• Provide easy gateways from that resource to more active participation in the Drupal community: IRC, issue queues, doc team, translation teams, GDO, etc.
• Improve the consistency of IRC and Q&A moderation by setting up a venue for moderator docs and discussion.

I was recently asked what one needs to know before becoming a Drupal developer. It's a tricky question, both because Drupal draws strength from the diversity of our community, and because it's hard to pinpoint the precise point where one becomes a dev. Below is my attempt at an answer

So, here I am, up far later than planned. If you catch any errors/omissions, please note them in the comments and I'll correct them asap.

Last night I had I had great fun talking about hacker culture with the good folks over at CINLUG, the Central INdiana Linux Users' Group about hacker culture. The session was not recorded, but below are links to the works I referenced, followed by my presentation notes (which are more like a rough outline and may or may not be useful to anyone else).

References:

These are in no particular order

DrupalCamp Indy 2010 is coming!  October 23rd will be here before you know it.

Here are a couple of fliers I put together, short but sweet, emphasizing our newbie-friendliness, awesomeness, and how we have something for everyone.  Please help us spread the word.

In the past couple of weeks, I've become increasingly aware of how much conflict younger open source projects I'm involved in have compared to more mature projects and projects run by folks with an extreme number of years in open source.

Then I had to explain to my housemate who Donald Knuth is...
...and tell a fellow Drupalista what the Jargon File is...
...and define "grok" for a colleague from the XMPP community...
...and stifle a laugh while my 7-year-old tried to describe the wumpus to someone who should know better...
...after which I read Eric Raymond's recent post on the social utility of hacker humor.

Then I grokked.

In the projects that have been around for a dozen or more years, or those run by hackers who have been, there is a common culture and identity shared by all: we're hackers. Whatever else we are -- country bumpkins, urbanites, gay, straight, bi, male, female, transgender, a particular religion or nationality, old or young, single or married, parent or not, rich or poor -- we are hackers, and all we need to know to work together is that we share that cultural bond of hackerdom.

I rarely write about feminism.  When I have, it has to point out the foolishness of pushing non-tech women into technology in the name of gender equality, and trying to obscure the ability gap by pressuring competent women to spend too much of their time with the incompetent ones.

This time I'm writing about a brilliant article I came across on twitter (thanks @crell).

I recently read a Stephen King quote:

"Speaking personally, you can have my gun, but you'll take my book when you pry my cold, dead fingers off of the binding."

...and I can't help but wonder how, without the gun, he intends to defend possession of the book.  (Assuming here that cold and dead is a suboptimal outcome.)

Many web developers, especially Drupal developers (who are in particularly high demand these days), won't touch speculative work, period. With so many options available to us, we can choose work that will pay now over work that might pay some day. Still, not everyone who has an idea has the front money to build it. I have had some luck with speculative web development work over the years, and I thought I'd talk about why I do it and how I choose which projects are worth speculating on.

Not long after I diverted from my former career path to pursue life as a Drupal consultant, I received the following advice from a trusted friend: "Every good independent web developer has a project or two that is their own, besides what they do for their clients." It's turned out that he is right. Good speculative work gives me a chance to build a product I'm really happy with, free of portfolio-harming client compromises and NDAs. It also provides me with important experience following a project through its entire life cycle, so that I can jump into my consulting projects and easily answer "where do we go from here?" no matter what state the site is in. Finally, good speculative work gives me something potentially profitable to do when my consulting business slows down. Instead of having tons of work or no work, I have tons of paying work and a little speculative work to fill in the gaps, which is better than no work!

Despite the potential benefits of developing a few well-chosen speculative projects here and there, there will always be far more demand for speculative development than there are developers available to fill it. I, like every other developer who considers speculative work, must somehow separate the wheat from the chaff. There isn't a formula for a successful project (if there were, we'd all use it and be rich) but here are some key points to consider before taking (or offering) a speculative web development project:

A 7yo boy was kidnapped from someplace in Oregon.  It's received the kind of coverage parents can only get when their missing child is cute enough to imply profitability to network news directors.  During a one-year period studied by the DOJ (stat via missingkids.org), an average of 2,185 children were reported missing each day.  Paring the news coverage down to the occassional poster child makes the subject more manageable, but it also gives the illusion that kidnapping is a rare occurrence.

Support leeches are a fact of life in the open source world.  Some people don't understand how to be worth supporting.  Others are just so obsessed with their own short-term wants that they are willing to destroy the community they are trying to get support from in the process.  Below are my observations, gleaned from years of actual support leech encounters.

Anatomy

There are two subspecies of support leech, however hybrids are not uncommon: