Respecting the proverbial frickin’ “box” in an open source software, do-it-yourself, “I ain’t getting paid a dime to do this,” world.
I hope this article does a respectable job of speaking about some concerns that I’m sure a large number of people have, as well as provides at least some food for thought as to where to begin looking at addressing the underlying problems and frustrations we are seeing within the Drupal community. If you read some things that you disagree with, as you inevitably will, please try to “hear” the underlying spirit in which it is written, which is a desire to help make Drupal as good as it can possibly be. Thanks in advance for reading…
There is a lot to be said for being your own boss. Most of what gets said is to do with the freedom. What you don’t hear most of the time is how there is so much freedom that it can crush you like a tsunami if you aren’t terribly careful of how you manage that freedom. Most of us who work for ourselves have had plenty of time in the corporate world working for others, myself included, so I totally get it when people involve themselves in various open source projects as a way to have the freedom to work and create what they want to, not what they have to.
Rethink, Refactor
Most projects, particularly in the way of code, spend their entire lifetimes in fledgling status, never quite getting broad acceptance and use, before being tossed aside and supplanted by something newer, bigger, better, faster, more usable, with that new thing exhibiting the results of lessons learned in building the former (or maybe it’s just your competition that’s besting your efforts.) That’s how it is with personal projects and it also happens to be the way it is with open source community projects, as development cycles run out of gas for various reasons, such as the code base hitting some walls that require major refactoring – gutting the system but keeping expected output the same for users to allow for new features and performance -as refactoring can seem less appealing than starting something entirely new. And after all, it’s your own work on your own free time and you’re not getting paid a dime for it, so why not, right?
So what about open source community projects?
In particular, what about very large open source community projects? Drupal has been from the beginning designed – from a code standpoint – to be modular. Drupal “core” has been kept, in truth, inflexibly small, as a result of a tradition of the well-intentioned development practice of making the base system run lean and mean and having users add functionality precisely as they see fit for their needs. This is still a great principle, but in a time when Wordpress – a much less complex blog and podcasting platform – is weighing in at about 2.8 megabytes for a compressed “core” download, comprising what even a basic blogger would consider a minimum level of built-in functionality, Drupal with its core functionality is a shockingly small 1 megabyte. A good thing? I think so, but a dogmatic adherence to the idea that Drupal core should be limited like this forces users to rely very, very heavily on community-contributed modules to do what are widely regarded as everyday, mundane tasks.
Okay, so no biggy, right? Not so fast – let’s think about the situation that we are putting people in for a second. To use Drupal – which we can all agree that users with larger projects should – we’re telling them that it’s not only okay for them to use “unofficial” software, but they should use it. Moreover, if they are going to use Drupal for anything beyond a blog (which would be the subject of an entirely different article,) they will have to use contributed modules. If this community were as similar to the Linux community as we sometimes like to think it is, these necessary ancillary pieces of software would either be brought into the primary distributions, or at the very least, have their own small community around the project that allows for an interactive development process with input from the outside – or it would wither and die, as it should, since it didn’t meet the needs of its users. The Linux community, through distributions, is all about finding the software that people need to get work done, packaging it, and making it relatively easy to use. Instead, we have module projects that are in wide use – sometimes tens of thousands of sites, each with their own user base, literally affecting in some way the online user experience of millions of people – with owners of the project sometimes approaching community/user input and feedback as though they were working on a classic car in their garage and a neighbor showed up adamantly suggesting that they change the color to day-glow orange.
In open source (I almost feel pressed to point out that it is open source, our beloved Drupal) when projects seem to be reaching a critical mass with an influx of fresh people and ideas that excitedly want to help improve a project, only to be met with knowing looks, eye rolls, and comments that scream “who the hell is this guy? (or girl),” and hundreds – or thousands, even – of people are all more or less saying the same thing, it’s clear that some rethinking of the entire process is in order, because the status quo way of interacting with the project is not working for them.
We’ve put users – not only individuals, but companies considering Drupal as a platform, as well – in a precarious position: 1) you must use contributed modules, 2) the contributed module you have to use doesn’t adhere to web standards or has other problems, 3) the user suggests what appear to be obvious industry-standard improvements, 4) the module project owner gets offended because another “parent” just corrected their “baby” on the metaphorical playground, 5) the user wonders what just happened, if it will ever work “right,” and why in the world this functionality isn’t in the original Drupal download in the first place.
So what’s up with the tag line? What about the “proverbial box?”
It might be shocking to hear it but Drupal is in desperate need of some leadership and a slightly more structured approach, going forward. Thinking outside the box is great until you realize that just winging it on a safari to darkest Africa without a map or compass to get into some “adventures” is a little more adventurous than you’d bargained for. Don’t ask. Open source can – and does – sometimes seem a little like the wild, wild west, with cowboys out there shooting their guns however, whenever they want. Eventually, though, even cowboys settle down and form democratic, organized cities, with processes for getting things done such as installing city plumbing, paved streets, and electing a mayor and council members to represent the citizens of their fair community.
Let me break it down for you: We’re hitting major pain points of large growth and we’re not going to reach enterprise quality like this due to lack of formal oversight of very key but “unofficial” modules, as well as a lack of front-end code standards in Drupal core. Our process that has served us well for years is becoming a real problem with the community the size it is now, because while from a code development standpoint there are fairly rigid standards laid out to developers to follow when writing modules or core code, there is no parallel process to that with standards that they are to follow with regards to design and front-end code, and that is very bad for Drupal. Having such high standards for writing PHP code while playing so fast and loose with front end code and treating it as though it’s a non-issue, even while the rest of the world does it this way, is not only a gross double standard within the Drupal community, it is currently beginning to get the attention of the Web world outside of Drupal — and not in a good way. We’re positioned in the press to take off like a rocket and gain real longevity, and yet in the web design community – people who talk around the world at conferences, on podcasts, et cetera – are starting to hear that Drupal, despite the good things about the code they’ve heard, makes minced meat of their beautifully executed, semantic XHTML, and there are no plans within the leadership of the Drupal community (yet) to raise the standard for front-end code to the same degree that they have on the backend. That’s bad for any one of us (myself included) who are making expensive business decisions betting on Drupal.
A few simple suggestions to begin making the Drupal family less dysfunctional
Firstly, developers take writing code very seriously and have stringent – but ultimately plain and simple – coding style rules to follow with their module development. Designers have the same sorts of practices. It’s what they do and it’s equally as important. It is time that that is fully recognized in the Drupal community and an effort be made to bring this paradigm (elsewhere largely already in practice) into our community. Designers feel just as strongly about a developer playing fast and loose with improperly written, unsemantic XHTML as developers do about designers who make dumb mistakes with PHP or try to talk shop when they are out of their depth. In fact, dare I say it – if you’re writing poor, unsemantic XHTML markup, it’s due to your lack of understanding of what you are doing, at this point. Web standards are widely adopted in the Web world. Drupal ignores this fact at its peril.
To that end and secondly, our community needs a Drupal Design Panel of people that are engaged in assisting module developers with design review and the Drupal.org infrastructure needs to support this end. There needs to be a formal, bidirectional process where module developers and designers can discuss issues with their implementation – preferably early on – so that mistakes with things such as web standards are easily corrected. It shouldn’t be that people doing business with Drupal have to worry about hurting someone’s feelings because a module is outputting XHTML that is so bloated and cluttered that it’s unreadable. A developer would not stand for that kind of sloppiness on the back-end and neither should front-end designers and coders have to. It is a fixable problem. People want to contribute their expertise, and if there is a problem, it would be much easier to address it through a normalized process and no one would have to feel like they were being personally disrespected because it would simply be “the way we do things around here.”
Thirdly, I’d like to propose that we use the resources we already have to better advantage, namely our Drupal Association. I am very much in favor of greater transparency and involvement of the Drupal Association around these sorts of issues, because as a person relatively new to Drupal compared to some (my drupal.org account says I’ve been on there for two years, eight weeks,) I’ve observed and experienced the confusion about how to participate and make things better. As it stands, the Drupal Association – which I pay dues to annually – is a bit of an enigma even to me, as to how it functions, how important decisions are made, and how to participate and involve myself in those processes. I know that my money – along with my registration fees – helps to pay for two semiannual DrupalCon events, but with a surplus of funds after D.C., and an increase in registration fees for DrupalCon Paris, there has to be resources to do considerably more, but I digress. I would like to see a more open, interactive process for the Drupal Association, complete with democratically elected officers, a nomination and public issue discussion in an open forum at the recurring, semiannual DrupalCons. I think that sub-community representatives (such as Development, Design, Documentation, et cetera) as well as future permanent members should be nominated and voted upon by the paying members of the Drupal Association. Most important to the discussion at hand, there should be a nominated and elected Design Liaison on the Drupal Association’s board, as well. As with any non-profit, members should be offered information regularly with minutes of meetings, full expenditure disclosure, planning disclosure, and the community can then suggest guidance and budget allocations for things that it sees fit, rather than this rather “gray area” process we have now that very few people in the community know how to engage themselves in. This might seem a bit disjointed to my article as a whole, but it is relevant to the discussion, because what we are ultimately talking about here is accountability and community planning — positively affecting the community that we are involved in. That planning has to address the needs of many more people than were originally planned for in Drupal and some evolutionary changes are necessary, particularly in the process and organizational structure area of things.
I know this article is a bit on the long side, but I had a number of things to say that I hope will be helpful. I’d love to talk at DrupalCon in Paris about these issues and hopefully we can begin to make progress towards an even better Drupal community experience. Thank you for reading.
Tags: community design drupal open source web design web standards
