It was peculiar yesterday that after reading and commenting on Drupal Is a Framework: Why Everyone Needs to Understand This  that I would find myself in an unrelated discussion with an unnamed Free Software giant - it started because I was sharing something I thought of use, but it switched to Drupal. There are thoughts on this that I tried to express before and suddenly it all clicked. I'd written it in the comment on the article but hadn't realized its depth until the discussion. It is summarized in one line:

A more thoughtful open source community would have forked the framework from the CMS.

Some argue that they are the same thing. No, really, they're not - and yes, the new path of Drupal is increasingly that of a framework - great news for developers who can't manage the low level despite severe browbeatings from Drupal Core developers (I have angered one in my time at Trellon and take perverse pleasure in goading him on occasion). 

A framework has higher overhead. Shared hosting does not have as much wiggle room. Most websites on the internet are on - say it with me - shared hosting.

Drupal's base, whether people want to acknowledge it or not, aren't the big sites with the highly paid development teams working on them. This contention was shared by community members at some Drupal Camps I was at - particularly in New York City. Of course, no matter what you do there will be some group that is unhappy with certain things about projects or corporate presences at the camps being... over-reaching.

Open Source has a great benevolent dictator. Linus Torvalds, who has had the pleasure of never having met me - we know some of the same people, we don't need to know each other, he does right by Linux, he keeps the kernel moving forward and has proven over the years that... he's the standard. Drupal lacks that.

Drupal has a tendency to break things from version to version. I call them temporal forks because small businesses and non-profits get stuck in them, little black holes of maintenance gone awry. This is one of the things that sucks about Drupal but no one really seems to discuss it because it's not code, and the Drupal community is driven largely by coders. It has been my experience over the years that projects such as that begin to be unconcerned about users and it's my contention that Drupal has not only gone down that path but beaten new paths into this - an opinion, if you would, of the unheard part of the Drupal community that lacks a say in how the project is driven. That is changing. Not everyone has a budget for an entire development team to work on their site with Drupal - but they can afford a Wordpress freelancer.

I have no problem with this direction of Drupal. I like to use the right tool for clients needs and, as a one person consultant/developer, Drupal is working its way out of my area. That's where Drupal wants to go.

Yet it's apparent that there are a lot of people out there who think Drupal should be a CMS but lack the intestinal fortitude to fork it. The Seamonkey Project did it when the Mozilla Foundation decided browsers with separate email clients were the way to go. If I were independently wealthy, I'd fork it. I would join in on something like that and help out.

For lack of a more thoughtful open source community, perhaps one should step forward. Or not.

I've been changing with the times for decades. I may not get to work with Drupal as much in the future.

Obla di, obla da.

"You're a software guy and you're writing about RX7 Maintenance on your site! You shouldn't do that."

That's an almost fair assessment. First, I'm more than a 'software guy'. It's my site, I do as I wish, SEO rules be damned. But it's deeper than that. It's really about quality and while this might not make sense to some of you it's my site and I get to explain.

Once upon a time at a company whose name starts with a big red H, a younger version of me had to deal with different departments regarding some software I had inherited and I got into lots of discussions and arguments with people in Software Quality Assurance, Software Configuration Management and Software Test. One day, David R., the head of Software Quality Assurance, were just talking. He told me that his favorite book was Zen and the Art of Motorcycle Maintenance: An Inquiry into Values. I'd read it as well but hadn't yet put it into the context he put it into as simply as he did one day as I stood chatting with him at his desk.

He said, "Quality isn't a bunch of requirements you meet. It's a feeling you get from knowing."

No, he wasn't a hippie. David was in the know.

Really, that's what it is. You can do statistical process control like Six Sigma, you can certify software through the SEI levels, you can do all of that. All of that gives you data to rationalize a feeling. With anything mechanical the feelings are easier to come by because quality is tangible. You can see it, feel it and know it all without a bunch of statistical process control.

Quality is about paying attention.

When your car or motorcycle does anything different, you investigate. It can be the odd sound, a different smell, a sudden pull to the left on the highway or a sudden drop in mileage. The more data you have, the more you can support that feeling. With a motorcycle or, in my case, an RX7, that knowing - understanding what is going on with a vehicle at any point in time - lends itself to expectations, and those expectations are what one would consider formal requirements in software development.

Quality is iterative. What passes for quality today may not pass for quality tomorrow. That sound you fixed yesterday may reveal a new sound you didn't hear the day before. You may fix one thing to find another needs fixing; this is the whack-a-mole of quality.

Quality is a habit. On complex projects, be it fiddling with a carburetor or dealing with object oriented code, documentation is a means of assuring quality through deepening understanding of what is happening so that in a few days you can go back and see what happened.

Quality is indefinite in every sense of the term. Quality has to be constantly re-evaluated in different contexts.

Quality is about knowing and part of knowing is knowledge. You can have a lot of knowledge and know nothing. Knowing is a bidirectional relationship with knowledge

There are those of us that develop relationships with the concept of quality. As someone who deals with abstractions, dealing with more tangible things is a relaxation and allows the pursuit of quality to be more easily rewarded.

Sure, I write about maintaining my car on my site. But it's about knowing. It's about quality. If you don't understand why information like that belongs on the site of someone who deals with software as an architect, developer, project manager and consultant... maybe you don't understand software as much as you should.

Maintenance is maintenance is maintenance. Exercising those muscles constantly builds stronger muscles.

Two seemingly unrelated things popped up over the last few days. One of these things was an article along the lines of a discussion I had not too long ago with friend Yermo about. Simplicity in software design. From Reducing Complexity: The Next Software Imperative:

...And that should be the goal of all developers to make an app so elegant, so well designed; you forget you're using it --or even the device on which it's installed. The reason people gravitate toward apps at work is because mobile devices often offer the most elegant solutions to long-standing problems. Instead of fighting with clunky enterprise software, users find software that does what they need it to do and nothing more --and more importantly that just works...

For those of you who don't remember what the Mozilla browser used to look like, as an example, one need only take a look at the community Seamonkey project, something I use every day because it does many things I want to do exceedingly well. It downloads my emails for me, something that it seems a generation has completely forgotten about unless they're locked into Microsoft Outlock Outlook. It has a built in HTML editor. It has an IRC component. It has an address book.

I'm not the norm. The Firefox project does one thing very well. It's just a web browser. Seamonkey and Firefox have the same engine underneath. Which one is more popular? I don't think I need to look for statistics to show you that Firefox is more popular than Seamonkey.

More popular examples would be apps for mobile phones. They do one thing and they do it well (unless it's something recent from Facebook, or so I hear). Simplicity.

Yet simplicity almost always masks complexity; it's a matter of who deals with it.

In a world of small or non-existent budgets and lots of well intentioned people, software developers inclusive, this can be a sticking point even when trying to do something pro bono.

As Jon Lebkowsky (of Polycot Associates) posted in a status update yesterday:

Never fails - you offer to build a website pro bono and the recipient of your love is irritated that you can't create a $20K miracle for nothin'. Hopefully I've learned my lesson, finally.

As someone who has found himself in similar shoes, I've noted this a lot. The '$20K miracle' here is the problem anyone dealing with any software development has run into, be it for a small business, a large business, a non-profit or a family member - or someone who heard from someone else that you do websites. Recently I have seen it twice - the first with developing an API for an web host company to wrap other disparate APIs. The second was fixing an old Drupal install to do something that has a module for it in Drupal 7.

I could go on. I imagine many software developers could, particularly those of us in contract/freelance mode.

The point is that client expectations are high but they fail to realize that a simple logo and textbox on a website - simplicity in and of itself - masks a lot of working code in the background. Who am I talking about? Google. The simplicity of the Google page is probably the best example of masking a lot of complex algorithms that provide people with, more often than not (we hope) what they are looking for on the Internet.

The tree, as simple as it may look, has complexity hidden below the surface in its roots.

With mobile development applications, it's the operating system and hardware. With Microsoft's .Net platform, it's an API that does a lot of the ground work and makes software developers into software librarians - a trend that the open source community has followed.

Move over Dewey Decimal System.

Simple for the user often translates into complex for the developer, depending on the requirements of whoever the software is being written for. TANSTAAFL. The more simple the outward appearance, the more likely the internals are complex - and increasingly, this seems less intuitive for people.

Complexity costs money. Making complexity look simple costs more. There is cost and there is value. A simple outward facing site like Google masks a complexity that costs a lot but clearly has a value greater than the cost.

The focus should be on value and simplicity or making complex processes appear simple - and keeping any complexity within budget. If that budget is 0, don't expect a lot of complexity.

Remember - users want simplicity or, better, they don't want complexity. Making your website or software project appear simple is the rub.