So, it's probably about time I took some thoughts that have been rambling around my head for a while and even spilled out a bit in #drupal here and there, and talked about what I think about "gold stars" for Drupal contrib modules.
Nick Lewis has written one of his usual thought provoking posts on the subject of having a "top tier" of contributed modules. I agree...in principle. But he's also wrong.
I've been an advocate for more access to all. Give that poor, downtrodden PHP programmer in the corner a CVS account. It will make them a better person, they'll learn best practices, and a glorious garden of contrib will flourish. Well...not so much, although there are some fantastic starting points out there in contrib, and a few great, solid pieces of code that perform yeoman work.
Want a gold star? Here's how to get one:
What are the consequences? Maybe only a select few get gold stars. Those with stars get more stars. merlinofchaos gets a new wizard robe, the rest of us have quidditch mud thrown in our faces.
But wait. Here's a suggestion. What if, if you don't follow these steps...you don't get publicly listed. That's right, forget the gold star.
What if, when browsing the downloads section for contributed modules, it only listed modules that met these standards. You could, of course, still get to those projects, and visit their issue queues, and link to them directly. And maybe, if killes is feeling especially generous and has had a delicious newbie snack to tide him over for a while, there's a special "I know what I'm doing and I really want to see the stinky code over the corner even though it will probably eat my baby" button/flag/giant padlock that you can click to get to browse through all the modules.
But the default is, no gold star, no public listing.
Perhaps even more radical – and if you pay attention to nothing else, internalize this bit – what if, on every project you worked on, every time you touched a contributed module, you did the following:
I think clients want tests. It reduces their maintenance costs long term. Oh? You thought you were buying a finished product? Remember, CMS is a project, not a product.
Do I need to write up the bit about having a "patches" directory, and a developer ticket which links to the patch and the drupal.org issue queue number, and that the work isn't done until the issue is closed and the code is resynced with the upstream tree? Let's take that as a given...
What would be the long term effects of individual developers and consulting shops adopting such a model? How much would the code quality improve over time? On the second project that you start, where 80% of the modules are the same as the last one, which now all have simpletests available, how much time would you save?
Some food for thought. I think it's a process I'd like to embark on. In the short term, it's going to be HARD. But in the long term, I think the mountain pygmies will thank us.