I’ve been using Drupal, an open source content management system (CMS), for the websites I manage for over four years now. Though there may be some quirks in working with an open source product, I cannot imagine doing it any other way.
Hesitations people may have when considering whether to use an open source product probably include the fact that you can’t just submit a helpdesk ticket when you run into a problem and expect a response within two business days. Most of the time, no single company or entity exists behind an open source project, like with a proprietary system. Instead open source has communities.
When you’re building your own custom system in-house, or you’re using another company’s proprietary software, there are a limited number of developers (your in-house developers or that company’s development staff) who are working on the system’s features. When you’re using an open source project, on the other hand, there are a far larger number of contributors as part of the community around the project. As an example, drupal.org recently reached 1 million accounts. Drupal.org, at the time of this writing, counts the number of developers as 32,468, however, many users contribute to the community without committing patches, so the number of contributors is much larger.
This single fact is open source’s greatest strength. As soon as a web trend emerges, and a customer notices it and asks me to include it on a website, chances are that someone else in the Drupal community (or a combination of people) will already have written up a module for that functionality. For example, when social sharing links started popping up, and a customer wanted to include them on their web pages, there were already a variety of Drupal modules that provided that functionality. I tested them, chose the one I liked, and easily included the feature on the website without writing a single line of code.
Similarly, creating clustered maps became a new feature on websites at one point. When our need to map North Carolina-based bioscience companies emerged, I was again able to find two stable modules that could do most of what we wanted (as a disclaimer, I did have to patch one of the modules to get it to do exactly what we needed, but it was a far cry from having to write a module myself).
When the new HTML 5 standard came out, the Drupal community immediately started creating new themes and improving existing ones to output HTML 5 and to take advantage of the improvements.
In short, when there is some new feature or improvement that is web-related, the active participants in the Drupal community are on it. All I have to do is search around to find solutions to almost all of my web-related needs. Most frequently, all I have to do is download a module that provides the functionality I need or update an existing module, as they are constantly expanded and improved by community contributors. That’s the real power of the open source community.
Contributing to the community
Now, of course, it’s not recommended that you sit around and let everyone else do the work. If we all have that attitude, there would be no open source projects. There are many ways to get involved in helping out with the open source projects you use. I’ve written patches to remove bugs or extend the features of modules, I’ve tested other people’s patches that needed testing and even just contributed to the documentation online, which is also community generated. Testing patches that others have written and enhancing the documentation is something that can be done even if you don’t write code.
Let’s say that I’ve contributed to 20 modules in one of the many ways described above. That may sound like a lot, but consider this: I use as many as 97 modules (in addition to core modules) on my busiest Drupal site. So you see how much we can all gain if each of us contributes a little.
It doesn’t matter how capable or active I am in the community. It would take me eons to write every web feature that I want to use from scratch: the ability to have comments, customized accounts for logged in users, social media sharing buttons, drop-down menus, clustered maps, customizable search interfaces, newsletter subscriptions, and so many more. Without being able to leverage the thousands of developers out there who are increasing the security, capabilities, and visual appearance of Drupal, I’d be able to accomplish so much less on my own.
Be aware of these differences
Cost
Whereas with a proprietary system you pay to use the system and for any related tech support, when you choose to use an open source software system, you get the system itself for free. Your cost comes from whether you choose to have an administrator and/or developer who can customize it for you and who knows how to work effectively in the open source community. Particularly if your needs require a lot of complexity and customizations, this very well may be a necessary expense (and may not be cheap).
Flexibility
Having an in-house developer working within an open source community will likely mean that you will get your customizations faster and more reliably than by requesting a brand new feature with a company whose system you’re using. Outside companies likely have many clients, and thus many requests, and yours may languish in a queue.
The decisions are community decisions
Sometimes you want to take the system or a specific module in a certain direction, but the community or the module maintainer may not. Most of the time, the opinion of the majority is the correct one. However, there can also be problems with the community model. For example, modules can become abandoned by their original authors and maintainers, and not in the planned, thoughtful "this feature will be deprecated" way of companies with proprietary products who give you a chance to stop using a feature over time. For various reasons, modules can just be abandoned. With active modules which have many users, this isn’t as likely, since others in the community would probably step in and help, but I’ve seen it with smaller modules on more than one occasion.
Additionally, the community or module maintainers may not agree with you on how a module should grow or evolve. I’ve seen module issues which are two years old with long discussions and participants numbering close to the 100 mark discussing not who should solve a particular technical bug, but how and even whether it should be solved. Sometimes different users want to use the same feature in a different way, and in cases like these, the module maintainer (a volunteer position) or a veteran Drupal contributor, may have a lot of sway, regardless of majority positions.
In Drupal, however, even if the community goes in a different direction with a module than you want, you can also write your own custom module that you can use, alone, and is separate from the community’s store of contributed modules.
These are just some of the subtleties of working with an open source software project. You have to learn how the community works, how you can contribute, how to report problems, test solutions, and contribute solutions yourself, as well as, what the limits may be on getting fixes and improvements. Each community has a different level of activity and a different number of users, both of which will affect the speed with which fixes and improvements of the product are generated.
In any case, you will get to use a whole bunch of code for free that is the result of tens, hundreds, perhaps thousands of individuals' work—a number you probably cannot afford to have on your payroll. And yet, with open source projects, you can get all the benefits.
3 Comments