So sánh Drupal vs SharePoint từ Developer's Viewpoint

After working in organizations that adopted both Drupal and SharePoint, I have been asked on several occasions my thoughts on the differences between the two platforms.  While I was developing a Sharepoint site a few years ago I remember looking around for comparisons and was surprised about the lack of information.  In 2007,Dries Buytaert, the founder of Drupal, wrote a post that really inspired me that I responded to in the comment section. 

Many of the comparative articles I found were written from a marketing viewpoint, but not actual developers who had hands-on experience with both frameworks.  Here are a few of the entries that found during my research:

In my experience, SharePoint does not live up to the hype for a variety of reasons. SharePoint 2007 is being positioned as not only an intranet platform, but also a web framework that can power big sites and be on the same playing field as other larger CMS platforms, like Drupal.

To preface, I am not here to argue with SharePoint's intranet capabilities. The platform has Microsoft product integration and file management features which Drupal does not have yet (other than some basic file manager modules to the best of my knowledge). As I understand, Drupal was never intended to do heavy lifting management of documents, but there is no reason why it could not grow as an intranet platform. However, that is a whole other discussion.

From my vantage point, I have identified six major differences between SharePoint and Drupal. They include:

1. Setting up a local development environment is difficult and expensive.

2. Setting up an efficient development/deployment process is cumbersome.

3. Theming SharePoint is extremely difficult.

4. Many SharePoint modules (aka webparts) are quirky and don't work as expected.

5. Lists and libraries are quirky and also often do not work as expected.

6. SharePoint is slow and does not give you real access to the database that powers it.

1. Setting up a local development environment is difficult and expensive.

First, SharePoint is extremely difficult to set up on a local box. That is because you need Windows Server to run a SharePoint website and you have to have a SharePoint site to create web parts for that site. Thus, either your local box needs Windows Server 2003 or higher or you need a virtual machine that runs both. Furthermore, developing in Visual Studio in a virtual machine is arduous. Aside from the CALs and licenses you need for each developer you are married to getting four gig or higher machines. Now, maybe we are already to the point where that is not as much of an issue, but at the time, several of my colleagues had two gig macbooks that could not be upgraded. Basically, we had to try to run a VM in one gig, which is basically impossible. What we ended up doing was using remote desktop to connect to our own personal instances of Windows Server 2003 where we could develop against a site that had four gigs of RAM. For the most part, we could run some Visual Studio and Designer Studio locally until we deployed changes that we might have to test on the VM itself. To summarize, getting set up is expensive and requires heavy hardware.

Drupal response:

Drupal is extremely cost efficient to get up and running. You can run Drupal on virtually any platform and you do not need a heavy-duty machine to run most sites.

Drupal and editor tools like Eclipse are both free to use. In addition, the entire catalogue of Drupal modules is open source, and many are very well supported by the community.

2. Setting up an efficient development/deployment process is a pain.

In my opinion, deploying a SharePoint site requires that most organizations have a Microsoft Server sys-admin. I really do not think most organizations that are deploying SharePoint sites (as external websites) can manage without a Microsoft sys-admin on the team. The fact that developers are handcuffed to a sys-admin even while developing is one reason deployment is a pain. Second, there are a multitude of steps for pushing web parts to different environments. And webparts are the easy part. Developers have to deal with compiling dlls and adding things to the GAC and configurations and restarting IIS, so it's not exactly plug-and-play. However, webparts can be streamlined. Pushing the entire site to another environment is also not really difficult. Basically, what is impossible is trying to push a subset of data. You might think lists and libraries could be exported easily but in fact when we tried we lost the associated metadata which basically makes a list worthless. To be frank, there is not a good way of exporting/importing data to/from environments. Our team had to create one development environment that was "staging” that was treated just like production because we would push to production eventually from staging. Again, all of this can be streamlined to some extent but getting to that point is a very frustrating process. We had three developers, a sys-admin, a SharePoint expert and it was still an arduous process.

Drupal response:

Setting up a Drupal development or production environment is also easy. With svn the development team can check out files onto a development environment and push its db changes. Drupal runs on PHP which runs on virtually any environment, and you don't have to be a server expert. Many people launch Drupal sites on shared environments without any deep technical knowledge.

3. Theming SharePoint is extremely difficult.

The theming process requires SharePoint Designer 2007. And that means more money will have to be spent for each copy of program, and that is in addition to the tens of thousands of dollars it already costs for all the other licensing an organization needs to get a SharePoint site up and running. SharePoint Designer is not terrible as an editor but the check-in, check-out system of version control can be maddening. It is very frustrating in my experience to work with a team of designers/developers/admins touching aspx files and constantly seeing that someone forgot to check-in a file. What this leads to is either you have to override it (which could make the other person lose their changes) or get the last person who edited the file to check it in. Doing so will not reveal the changes to a public user so you must also then publish the file. Publishing files in SharePoint Designer gives you an error (has this been fixed?). To further complicate matters, you then have to log onto SharePoint and drill down to the file to publish it for anonymous users to see the changes.

If you can get past file management you will find that doing any amount of theming in SharePoint requires some knowledge of XSL. Other Content Management Systems (CMS) use XSL and there is probably some valid reason why though I don't know what it is, because I find it very limiting. I prefer Drupal templates that are more straightforward and can use PHP to manipulate the theme layer. With XSL, you have to find XSL functions to try to accomplish what you want and again that can be very limiting. And I never understood why aspx files do not have conditionals unless C# is enabled (which is a security risk). Why is that important? Because often times you have markup that you do not want output unless you get a value you are expecting. For example, if you are styling a div a certain way, you might want that div only be rendered if it has a value, I ended up having to use jQuery to get around these limitations.

Finally, SharePoint's markup is completely terrible, non-standards compliant, and non-sensical. There are some CSS files and ids/classes in SharePoint markup, but they are completely misused. To list a few items: really long IDs, embedded tables, inline css and non-standard compliant html. This is very difficult to style unless you have an out-of-the box SharePoint site or buy a pre-made cookie-cutter template for the site. And that underscores the problem of SharePoint 2007 growing out of an intranet platform into a supposed web-publishing platform. When SharePoint was merely an intranet platform, theming didn't matter much because it was only seen by employees. Now developers are being tasked with creating widgets and creating layouts but the theming layer is just is not up to par.

Drupal response:

Drupal's theming layer is very powerful and flexible. It is constructed in a way that scales well with a themer's knowledge, meaning the more you know, the more powerful it is. But a lot can be done with CSS and a few template changes. It does not require in-depth knowledge of phptemplate functions and form overriding, but it helps to learn such things when you get into advanced theming. Also, everything is in PHP so if you know PHP it is easy to get started.

4. So many SharePoint modules aka webparts are quirky and don't work as expected.

The Content Query Web Part (CQWP) is supposed to be this heralded feature that allows for pulling content easily, but I contend it is not. First, the output is hard to theme. That goes back to my point about having to work with XSL. And many of the XSL templates are in tables. A big problem with the CQWP is that it does not ship with anonymous access. Developers find out quickly that getting anonymous access to certain features, like the blog for example, is not so easy. You can read more about a workaround to this issue here. It goes back to my central point, the question one must ask – “Why is this so hard?” Why do developers have to waste time finding a work around for something so simple? And this raises the question also, why has this not been fixed? I contend that if a problem like this existed in a Drupal core module it would be fixed immediately. And that is the advantage of having a community supported platform instead of a system that only gets upgraded every couple years and charges money for those upgrades.

Drupal response:

Drupal core modules make sense. The top contributed modules make sense. That is because there is an active community behind Drupal modules and not a large inefficient corporation. The Views module beats the CQWPby a huge margin, in my opinion. The power of Views 2.0 especially is amazing and CQWP simply does not compare. Views allow for ultimate flexibility and have a powerful theming layer. If you want a more powerful CQWP you have to pay for it from a vendor that creates an advanced webpart or search places like CodePlex, which does not have near the number of developers in its community.

5. Lists and libraries are quirky and also often do not work as expected.

We already addressed the quirkiness of exporting/importing list and library content, but there are also strange permission issues that come up. Some list data in particular is not available anonymously, such as most notably the calendar item list. The problem is not viewing an event in a list, rather the problem occurs when the user clicks on an event to view the details. That will by default prompt a popup authentication box which for a public website is typically not the intention. So far all the granular and inherited permissions SharePoint has items like this fall through the cracks. Our team had to find yet another work-around to solve the issue, which involves a small hack to an include file somewhere. It is possible at the time of this writing, some of these issues have been fixed, though let the record show that Sharepoint was released in 2007 and our team had these problems into early 2009. Also, there are inheritance problems when you get into lists in sub-sites that is beyond the scope of this discussion. The point is that lists and libraries which of comparable to “node” content in Drupal, are entirely too obtuse and don’t work in a straight-forward matter when it comes to web-publishing.

Drupal response:

Drupal's node system is amazingly more powerful and easier to use than lists. The Content Construction Kit (CCK) allows for tremendous flexibility and power with content, often times not requiring deep technical knowledge. For libraries, developers can create files with meta data using CCK that emulate some of the features of libraries though it is not an exact comparison. Namely, there is no messy inheritance to deal with when managing node content types. Instead of inheritance, CCK uses composition which in my opinion is much more flexible and easier to understand.

6. SharePoint is slow and doesn't give developers real access to the database that powers it.

SharePoint does not give developers access to the SQL database that powers it, well technically they cannot prevent them from touching it, but that can lead to data corruption, so it is really not a good idea. Furthermore, even if one could analyze the database the structure is difficult to understand. One issue I have is that SharePoint stores everything in blobs. That to me does not seem like a really scalable solution. Also, sharing data requires the “Business Data Catalogue” and more confusing tasks in order to share data with another system. Our team did not get into that too deep on the project we worked on so I can’t get into great detail regarding the BDC.

I do find it problematic that developers cannot access the database. I think ASP.NET developers and open-source developers are quite used to dealing with the database directly so it can be frustrating to not have access when troubleshooting issues. Developers do have access to an API they can use from within SharePoint as long as they are running SharePoint on the same platform they are using to write code. The problem is that often time developers need access to the data in another environment like staging, for instance. Copying all that data is a hassle. Another option is to fake it locally, but then problems can occur when that webpart is pushed to production and it does not work as expected. And so SharePoint is not exactly the snappiest site in my experience. I do not have benchmarking statistics. I am just speaking from personal experience. The instance on our local boxes consumed a lot of resources and development was on a high end server and still not very snappy. Our team ended up using a system where we had a content server that pushed data to a static server. That ended up being a pretty efficient solution, but cost can be a factor there as well when you are talking about a multi-node system. The problem with that kind of a setup is that it means updates are delayed – for many organizations that is simply not an acceptable solution. Many publishing sites require content be updated immediately.

Drupal response:

Drupal gives you real access to a real database and it's actually optimized out of the box and makes sense. Developers can inspect the database tables and make sense of what is going on. This is not required for a non-technical user, but is very handy for a developer. Drupal gives you many out of the box performance features like caching, menu caching, form caching, page caching, CSS/JS caching (a fantastic feature) and block caching. Those default options alone give sites big performance gains. There are still ways for a programmer to create an inefficient site but in my experience most popular contributed modules are well-tested and perform well.

To recap, I hope that this article was helpful for developers or managers looking into SharePoint vs. Drupal. My objective was to give an in-depth look into the two platforms from a developer on the front lines, who has actually developed for both platforms. There are many posts out there on the web from people who have not actually programmed against one or either platform and therefore cannot give an accurate comparison. SharePoint does not fail in the abstract, no platform does. My point is that the abstract features of SharePoint are not the issue, it is the real-world implementations of the platform that leave it severely lacking when it comes to web-publishing.

It is my opinion that this can lead to a development staff being saddled with a platform that can be very frustrating when it is found out it does not live up to the hype. My aim has not been against SharePoint’s intranet capabilities, rather Microsoft’s claims that it can be a major player as a web publishing platform. Also I would warn that businesses investing in proprietary tools of this size could fall into a perpetual upgrade trap – once you put money into a platform this big it can be difficult to leave. Therefore, for all the reasons I have detailed above, I implore managers to save the headaches and dollars and invest in a powerful community supported platform like Drupal. You will not regret it.