You are here

Continuous services and connected devices

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.

The commercialization of a volunteer-driven Open Source project

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.

Chrome Citizen Messenger Bag review

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!

Code freeze, module maintainers and veggies

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!

Clickability FUD on Open Source versus SaaS

Clickability, a proprietary SaaS platform for content management, has compared SaaS to Open Source. Not only is the comparison inaccurate, it omits the downsides of SaaS and frankly, they are comparing apples to oranges. Open Source is a licensing and development model, SaaS is a software delivery model. Either they are distorting things on purpose, or they don't understand Open Source at all. In other words, time to look at some good ol' FUD and to share my take on Open Source versus SaaS.

To give you a sample of their comparison, take Clickability's take on integration:

Clickability integration

Screenshot taken from <a href="http://www.clickability.com/SaaS_versus_Open_Source.html">Clickability's SaaS vs Open Source comparison</a>.

One of the biggest advantages of using Open Source software is that there are no limits on what services you are "allowed" to integrate it with. Given the number of sites that Drupal powers and the size and strength of the Drupal project, official integrations with other software and service vendors are abundant for Drupal. If you need integration, for example, with a highly specialized, niche product or web service, it may already exist among the 6,000 contributed modules for Drupal. If it doesn't, you are free to create it yourself. The same is true for other Open Source projects. Good luck getting that into the development cycle of a proprietary SaaS platform.

In many ways, Open Source is actually less risky than putting all your eggs in a single proprietary-software-basket. If you are unhappy with a particular Open Source company or service, you can take all the code and go to the next company.

Or take their section on hosting and performance:
Clickability performance

Screenshot taken from <a href="http://www.clickability.com/SaaS_versus_Open_Source.html">Clickability's SaaS vs Open Source comparison</a>.

I won't even begin to debunk what they write on self-hosting -- it doesn't have anything to do with being Open Source. Suffice to say that the great thing about FUD is that it validates our work in the Open Source community. They wouldn't have such a comparison page if they weren't worried about Open Source disrupting or slowing down their business.

My take on Open Source versus SaaS?

It is true that SaaS enables organizations to save money on hardware, configuration efforts and avoid hosting and maintenance hassles. However, proprietary SaaS vendors like Clickability need to ask themselves what happens when we start building SaaS solutions based on Open Source values. Open Source SaaS offerings, like Acquia's Drupal Gardens offer the convenience and support of SaaS multiplied by the benefits of Open Source.

Pages