I’ve gone back and forth on this for a while now, but from a practical basis I’ve made a decision. Not that I haven’t made this same decision multiple times in the past months, and each time in a different direction. But I’ve found myself spending almost all my time in one camp for the last few months as I pursue architectedfutures.NET, and I find my intention is to stay in that camp unless something significant proves unworkable. In my way of thinking, that’s worth logging as a decision.
I’ve been holding back from declaring a ‘final’ choice in this evaluation because I was still waffling, I wanted to make an informed decision and I wanted my decision to ‘settle.’ Now, after having spent some time working with both WordPress and Drupal, building prototypes and testing various versions of what I want to do with architectedfutures.NET using both systems, I’ve decided to spend my efforts going forward working exclusively with Drupal as my platform of choice. This is definitely not the decision I would recommend for everyone. And it’s not the decision I saw myself making once I broke out and began seriously exploring BuddyPress last year. But it’s the decision that I believe makes the most sense for what I am trying to do, the way I’m trying to do it. What I’ll try to do in the rest of this post is explain some of my reasons for going this way. What I’ll also do as I go forward is to show how I’m planning on using Drupal to build architectedfutures.NET. What are some of my detailed functional requirements? How am I getting those requirements satisfied? What problems and technical issues am I running into, and how am I going about resolving those items? As I’ve mentioned before there is no fully correct answer, and there is no free lunch. There are going to be some problems and frustrations with Drupal. (I’ve probably picked the more difficult path to follow.) But it’s a new year and it’s time to formalize a decision and move forward with the project.
Recap
How did I get here?
My Road to Here and Now post defines the general back story for this journey. It talks about different tools and approaches that I’ve tried over the years and how the scope of the effort has grown over time. It also provides some introduction to the essential elements of my problem space, my Entity Architecture Tool Suite™ and communities of practice.
In Part 1 of this series I presented my first Drupal versus WordPress contrast relative to my objectives. I also took some time to talk about functional and non-functional requirements, and I explained how to use a decision matrix for scoring criteria.
In Part 2 I talked about my goals and objectives. I talked about what form of social network I want to support with my website and who the participants are likely to be. I also discussed how I might handle a situation where the software solution might be different in the initial launch stage than at a later stage with a mature community. Given this framework I then defined a high level specification for the software to support my planned website.
In Part 3 I reflected on Architecturally Significant Requirements – ASRs. For me, this is the critical area for the decision, especially when dealing with a choice where the functional requirements don’t define an overwhelming favorite. Key ASRs discussed in that post included learning curve requirements, the customer focus of the support organizations and the “architectural match” between the alternative platforms (Drupal or WordPress) and my intended website.
Today’s post is an extension of the discussion on ASRs that drove toward the Drupal decision.
Decision Factors
Security
One of the tasks I accomplished after writing my last post was to undertake an analysis of security concerns I have for architectedfutures.net and an evaluation of how well those concerns are addressed using either of the two proposed platforms. I spent 35 years working in a corporate IT environment and security ranks as one of the top concerns in my mind. In this area I found the following differentiating factors to be significant in my decision:
- Organizational focus on security – I like the idea that the Drupal community includes a security team who take on the task of inspecting Drupal core and community contributed modules for security risks, and, after fixes have been identified, informing users of the potential problem areas. WordPress, to my knowledge, has no such program or process. In fact, I find it disturbing when I read advice in the WordPress community that advocates security through obfuscation.
- User roles and permissions are a cornerstone of Drupal thinking. The permission system (which users are authorized to do what functions or see what data) is an integral part of the Drupal architecture and an element that is part of most community contributed components. This is a far more advanced and comprehensive approach than that implemented by WordPress.
Required Functionality
All of the critical things I had on my list of functional requirements could be implemented using either system. That’s partly why I was waffling in my decision. However, there is a certain style or approach to the way the features are implemented in Drupal that I find more appealing. I find the implementation of the Drupal core functions, and the suite of capabilities implemented by the Drupal community, more in line with my tastes, my desires and my objectives. I feel that Drupal offers me a better CMS base platform on which to build a customized system of my own design. In terms of how those specific capabilities match to my functional requirements, my intention is to focus on different details of what I’m doing in follow-on posts. I’ll explain the approach I’m taking for selected features and how I’m addressing the requirements with different Drupal modules.
Functional Richness and Granularity
Functional features are something where either system can be programmed to implement a custom module to perform some identified function. The question is, how many of those modules already exist in useful form, or do you have to code most, or all, of them yourself. The available feature set is something that gives you an idea of what the rest of the user community is doing with the system. Where is the community going and what might you expect to find in the way of contributed modules over time. This is the area where I was very impressed with the activity I saw happening with the BuddyPress plugin for WordPress. However, after working with Drupal 7 for a while now, I’ve found a number of significant capabilities that are hard to ignore. This includes not just capabilities similar to those available in BuddyPress to support an online community, but other facilities like RDF web page encoding and related tools to enable the semantic web. And the structure of the feature set is more to my liking.
With WordPress/BuddyPress I found myself working with course grained function sets. This was nice in terms of getting a large block of functionality working quickly. But it becomes more difficult to shape and modify how the details of that package work, and then to be able to keep up with new revisions as the base software is changed. With Drupal it is sometimes very hard to figure out how best to put together a collection of finer grained modules to collectively accomplish a larger task. But when you piece things together component-by-component you get a collection that is much more tailored to your objective, and the individual parts are easier to replace or modify without as many issues coming up in terms of maintenance over time.
CODE MANAGEMENT
There are a number of factors related to code management that caused me to move back and forth between Drupal and WordPress. In Part 3 of this series I opened the post talking about change and change management. A major concern in my head was quick movement between major code releases in an open source world driven toward change. WordPress has some nice attitudes and practices which I appreciate. These include providing code warning messages and publishing lists of deprecated functions, and attempting to maintain some backwards compatibility before dropping an obsolete technique. New major releases of Drupal provide no backward compatibility with the previous Drupal code. There is a data contract but no function contract across major versions. In the beginning I was very much taken aback by this Drupal philosophy. However, now that I’ve worked with it for awhile, I’m still not crazy about the policy but the practical effects seem a little less onerous. I’ve found some mitigating circumstances.
- For one, Drupal maintains coding conventions and standards for contributed code. There is a project in the Drupal contributed code library named Coder which can be used to perform an automated code review of any module. The Coder project also supports a module which can be used to assist in upgrading modules from one major version to another. So, if you happen to be using a module which has been abandoned by its support team, and you need that module in your system, you at least have a fighting chance at being able to upgrade the module yourself to keep it functioning in an upgraded system.
- For another, the major code release and adoption cycle for new versions of the Drupal core may not be as quick paced as I anticipated. This is something that will take time to determine, but the adoption cycle for Drupal 7 has been slower than I expected. It may prove that as the user base builds up, there is a longer time delay between major releases. An interesting observation in this regard is that Acquia, the company led by Drupal‘s founder, Dries Buytaert, offers hosted versions ofDrupal as a service product. At least some of these versions are still operating onDrupal v6 almost a year after Drupal v7 was released. If Drupal‘s policy is to only maintain and support two major versions for bug fixes and security releases, I have to assume that either the Acquia product suite will migrate to D7 before Drupal v8 is released, or the policy will change to support three versions. In any event it is helpful to have the company dealing with issues as a co-consumer of its own policies. (Note. A similar situation exists with Automattic‘s operation of WordPress.COM. Although in that case there is less dependence on contributed plugin modules. In the case of Drupal Commons, the Acquia community site package I investigated, it is community provided modules making up part of the package functionality that is preventing the move to Drupal 7. That puts Acquia in a position a lot closer to its user base.)
- Lastly, I like the visibility of release differentiation and compatibility as handled by Drupal compared to WordPress. On the WordPress.ORG download site there is a single version published for a plug-in module. Typically that version has a statement by the author that it is compatible between a minimal and a maximal version of the WordPress core. Sometimes the most recent version published for compatibility is obsolete because the author hasn’t updated it, but the code still works with newer versions. As a second point of reference there is a place for user’s of the code to record their experience matching a module version with a WordPress version and voting it up or down. Its something of a crap shoot if you want the functionality the module promises but it doesn’t quite match up to the core version you are using. (And ideally you should be trying to stay up to date with a reasonably current core.) With Drupal you are dealing with two major releases of supported core code. And user contributed modules are hard coded to claim compatibility with a specific release of core. A claim that is enforced by the core code. On the Drupal.ORG module download site modules can be searched and are identified for download for Drupal versions from 4.7 through the developmental version 8. Most modules continue to offer their most recent versions for old releases for download, even though the code may no longer be maintained. And most modules offer current production releases, alpha or beta releases of new versions as they become available, and downloads of development releases (which sometimes include early access to fixes for reported problems).
Alignment With EATS™
Compatibility and alignment with EATS™ concepts and ideas was something I did not really expect to find. When I was considering building architectedfutures.net with Drupal 6, and when I was considering building it with WordPress/BuddyPress, EATS™ was a separate entity in my vision. What I envisioned was the community web site providing a vehicle for documentation and discussion about EATS™, but that the actual prototype and development would be done in Java as a separate entity. Now, with Drupal 7, I find that limited vision being challenged. A full-blown, fully implemented EATS™ platform still probably wants to be implemented as a Java (or similar language) installation, not PHP. But some form of an early, experimental version might actually make sense under a Drupal framework. It’s to early to tell how that might work out, but that would be a very nice outcome.
Conclusions
As I proceed with my task, I find that some of my concepts are changing. This is entirely typical. It’s very hard, if not impossible, when setting out to create a new system to completely and accurately specify all of the details of how the final product should behave. That’s partly why we have found some success in systems development by moving toward iterative development methods.
One of the things that I’m finding is that I want to build my platform using tools that provide me greater facilities as a web development platform, rather than simply a publication and interaction facility. And, while I’ve spent a lot of my professional life as a software blacksmith, building my own tools, I want to be able to spend more time experimenting with and integrating tool sets built by others, rather than needing to construct almost everything on my own.
This is what’s led me to move forward with Drupal as my platform of choice. I hope that by having documented some key aspects of how I’ve made my decision, I’ve shed some light on the process so that my journey can also help you in making a better choice for your project. In some cases by selecting a different route.
Thanks for reading, and “good luck” with your effort.