Ten years ago, the average organization had one website. Since then, the world has become a more complex place with a diverse set of needs. If you're like most organizations the number of sites you have continues to grow at a rapid clip. You've dipped your toe into the social media waters by setting up one or more blogs, you use microsites for the foundation of your marketing efforts to promote products and events, and community sites to engage with the people who use your products. And of course, you have your corporate website, as well as your intranet and a number of internal collaboration websites for different projects. This is today's reality.
During the past year, I've met with many organizations that have hundreds of sites; some even have thousands of sites. Most of these sites are vastly different in terms of scale, functionality, complexity and longevity. As a result, the level of investment and the time to market requirements are usually very different. Some of the websites are owned by the company's IT department while other websites may be owned by their marketing department.
For most organizations, one tool cannot get the job done, so they keep multiple tools in their toolbox - whether they intend to or not. Unfortunately this is a common scenario in many enterprises. We see many organizations that run on Vignette, but they add WordPress to power their blog, and use SharePoint for their intranet. Managing integration and multiple (proprietary) solutions is not only costly but it acts as a roadblock to innovation and slows time to market when changes are needed.
It can be a complete mess.
CIOs are now waking up; they're realizing that the cost of running twenty different content management systems on twenty different stack configurations is an expensive, unnecessary burden for the organization. They can see that there are cost savings to be made if they standardize. What they want is something more than a content management system: they need a single platform that meets their needs. They need Drupal.
The New York Stock Exchange is launching 30 sites on Drupal. Turner Broadcasting is migrating 80 sites to Drupal. A large consumer pharmaceuticals company might end up with over 3000 Drupal sites. Why? Because Drupal gives their IT team an agile platform to deliver new sites quickly with the breadth of capabilities to meet their needs, but broad enough in scope to serve as a web platform too.
More and more, I see large organizations standardize on Drupal. Drupal's low-cost entry point and open, modular architecture provides the perfect foundation. Drupal is one of the few solutions that can scale from very small to extremely large, and has the depth and breadth of functionality to support thousands of different use cases. Drupal sites can span a wide range of functionality; from blogs, to marketing microsites, social business community sites, corporate intranets, e-commerce sites and more. There are incredible success stories for each of these use cases already. Plus, we've now reached a point where many open source content management systems outperform proprietary solutions on technical superiority and pace of innovation. Drupal is in a very unique position.
This is an immensely powerful trend. If we navigate this well, Drupal could become truly ubiquitous and go from powering 1% of the web, to quickly powering 5% of the web and even further. It requires us to keep making Drupal a better platform, to crack the code on how to make Drupal distributions truly compete with commercial point solutions, and to build out an even larger commercial ecosystem and community. Needless to say, I'm super excited about Drupal's future and the opportunity ahead of us.
Ray Ozzie, who took over the role of Chief Software Architect at Microsoft when from Bill Gates retired about five years ago, announced recently that he will be retiring soon. When Ozzie first became Chief Software Architect, he wrote a famous 5000-word internal memorandum titled, The Internet Services Disruption. The memo outlined the transformative and disruptive potential of web services.
Ozzie wrote, "The ubiquity of broadband and wireless networking has changed the nature of how people interact, and they’re increasingly drawn toward the simplicity of services and service-enabled software that ‘just works’. Businesses are increasingly considering what services-based economics of scale might do to help them reduce infrastructure costs or deploy solutions as-needed and on subscription basis.". Ozzie was spot on as this is what today's Software as a Service (SaaS) and Cloud Computer are all about.
Now, five years later, just before he is about to retire, Ozzie wrote another 5000-word memo entitled Dawn of a New Day. In this memo, Ozzie reflects on how Microsoft has been transformed over the past five years with regards to so-called 'services'. Despite many successes, Ozzie acknowledges that for the most part, Microsoft missed the boat on mobile and social software.
More importantly, he also lays out his vision of where things are going in a post-PC world: "To cope with the inherent complexity of a world of devices, a world of websites, and a world of apps and personal data that is spread across myriad devices and websites, a simple conceptual model is taking shape that brings it all together. We’re moving toward a world of 1) cloud-based continuous services that connect us all and do our bidding, and 2) appliance-like connected devices enabling us to interact with those cloud-based services."
I spent most of my evening reading both memos. It provides some unique insight about what it means to be Chief Software Architect at one of the largest software companies in the world, as well as how they see the future. In general, I agree with Ozzie's vision of the future as he explains it in his latest memo. The part on complexity also resonated with me. I think the points he makes are very relevant for most of us that make a living with Drupal. Like Ozzie, I think development of this new service-connected world will be neither fast nor easy. However, I think Drupal is uniquely qualified to play a prominent role in such a world. It requires us to make the right decisions, to manage complexity, and to stay on top of our game. Whether you like Microsoft or not, the memo is worth reading.
In the Open Source software community, there is a considerable nervousness regarding paying people to work on volunteer-driven projects. For example, Joomla recently hired some developers to work on their core software, a decision that has caused much debate in their community. At Drupal, we recently hired a temporary staff to help with the Drupal.org redesign. There is an understandable concern that the spirit of volunteerism will be lost or a volunteer project will be tainted when a paid staff is introduced. There are worries that a project's agenda will change to suit the needs of 'privateers'. However, many projects that rely completely on volunteers fall short of what can be done by a paid staff. Some projects can't afford not to make use of the benefits that a full-time, focused staff can provide.
The concept of major projects growing out of a volunteer, community-based model is not new to the world. Throughout history there are examples of pure volunteer organizations that were instrumental in the founding and formation of many projects. The first trade routes were ancient trackways which citizens later developed on their own into roads suited for wheeled vehicles in order to improve commerce. Transportation was improved for all citizens, driven by the commercial interest of some. Today, we certainly appreciate that our governments maintain the roads. However, we still see road signs stating that a particular section of a highway is kept clean and trim by volunteers -- at least in some countries. When new ground needs to be broken, it's often volunteer communities that do it. But a full-time, paid infrastructure can be necessary for the preservation and protection of what communities begin. And when new advances are to be made or gaps to be filled in, volunteers rise up within the paid infrastructure. There will always be a place for volunteers, just as there is a place for professionals.
It's quite common in the software industry that great movements are started by volunteers. While this can work quite well initially, there comes a time when a volunteer-based project becomes a threat to larger, controlled organizations (e.g., MySQL to Oracle, Linux to Microsoft). At that point, if the Open Source organization is to survive and compete, it may have to fortify its position by fostering commercial involvement that helps the project advance and compete. Red Hat is a good example. Without Red Hat, Linux might not have the strong market share it has today. It is also one of the reasons I co-founded Acquia, and why it is important that all Drupal companies contribute back to the project.
Within the Drupal project, we don't have a paid staff to advance the core software. However, many of the developers who contribute to critical parts of the Drupal code base make their living by building complex Drupal websites. Some Drupal developers are paid by customers to contribute their expertise to the Drupal project or are employed by companies 'sponsoring' Drupal development. Tens of thousands of developers are working with Drupal today, and many of them contribute back to the project. Albeit different, neither Joomla or Drupal are exclusively a volunteer run project, and that is one of the reasons we've grown so big. Ditto for WordPress that gets a lot of help from Automattic.
Volunteers rally together at times when they're needed and they play a critical role, particularly in the beginning. Without them, we would be nowhere in the Open Source software industry. Over time the maintenance and operation and in some cases the leadership are transferred to paid personnel. We have to accept into our projects those with commercial interests, without capitulating to rigid and narrow commercial interests. The commercialization of a volunteer-driven Open Source project is part of a project's natural life-cycle. While it can be a significant change, it is a great opportunity. We can reap the benefits of growth, prevent volunteer burn-out and distribute the effort.
Like all the hipster fixie kids in the hilly San Francisco, I recently bought a Citizen Messenger Bag by Chrome. I sport the black on black version. Over the last two months, as I've actively used it, I've come to conclude that this is quite possibly the best bag ever made.
Technically, the Chrome Citizen Messenger Bag is not a laptop case; it is designed by bike couriers for bike couriers. That said, I use it for my everyday activities, including business meetings, conferences, day trips, etc. It stows my laptop, my Kindle, my iPad, a notebook, a jacket, my camera, a water bottle and more. I definitely recommend this bag to anyone who likes to carry a few things around. In fact, this was the first bag big enough to hold all the schwag I got at DrupalCon -- and that means something. But if all you need to store is a laptop and a few other items, it's still a great bag as it compresses down.
As someone who travels a lot, I need a bag that can handle a lot. The Chrome Citizen bag is built like a tank; it's made from weatherproof heavy-duty 1000-denier Cordura with a weatherproof liner and sealed seams for serious protection. The shoulder strap is made of seatbelt material, which obviously makes it mighty tough. The bag is extremely durable and has proven to be waterproof, even in pouring rain. It is the first bag that I have owned that comes with a lifetime guarantee.
I'm thinking about buying the accessory pouch for quick access to my cell phone and wallet but it might be a bit small for both.
Chrome bags cost a bit more, but so far it has been worth every penny. Highly recommended!
Besides working on Drupal core, I help maintain one contributed module: the Mollom module. It reminds me what it’s like to maintain a contributed module and to depend on Drupal core, what it’s like to develop a module with a constantly and sometimes rapidly changing core. It is healthy.
I was involved in maintaining the Mollom module throughout the entire life of Drupal 6, while Drupal 6's API was strictly frozen. We ran into a number of Drupal 6 bugs and limitations, but worked around them as best as we could in less than elegant, but in creative ways. The Mollom module may seem simple, but I can assure anyone that it’s not. For example, to insert a CAPTCHA it dynamically alters the forms in a way that pushes the limits of Drupal's Form API and implements advanced client-server communication over XML-RPC.
We began the Drupal 7 port of the Mollom module in January 2010, roughly 9 months ago, shortly after we put our pencils down on Drupal 7 development and started working towards the final Drupal 7.0 release. We have maintained and improved the Drupal 7 version of the Mollom module ever since. We even added features not available in the Drupal 6 version of Mollom, and we're using it to protect thousands of Drupal Gardens sites. Of course, this meant that we had to keep up with last minute API changes in Drupal core. But, in the end I think the energy and time we expended were justified.
Not only is the Drupal 7 API much improved and we were able to throw away large chunks of code, we were also able to make both Drupal core and the Mollom module better along the way. Through our work on the Mollom module, we were able to fix bugs in both Drupal's Form API and XML-RPC backend, to name two examples. This includes the kind of bugs that we would not be able to fix after Drupal 7 has been released. The result is not only a better core, but also a better module that is easier to maintain. To me, this approach is well worth the extra effort it takes to make some Drupal core API changes.
So I wonder why so many module maintainers wait to upgrade until Drupal 7 is released. We've learned important lessons from the Drupal 6 release cycle, but we can still do better; only 10% of the Drupal 6 modules have some sort of Drupal 7 release at this point. Code freeze is an ideal time for module maintainers; it provides a chance for module maintainers to catch up, fix problems and to make their modules shine.
Upgrading modules early during a code freeze is like eating vegetables; you should do it!