Our Drupal Product Manifesto

Next week Drupal people will converge on Rome to discuss Drupal Products. Given that we are developing a product for the travel industry called Drupal Rooms I signed up and I am looking forward to meeting with others and sharing experiences and ideas. In this post we describe our approach to building a Drupal Product.

Recently, Karen of Phase2, eloquently wrote up, what her vision of the future of Drupal products is. It is a marketplace that is community-owned, behaviour is ethical and does not subvert the open source ethos, and community contributions (as in contributions to the Drupal project and its modules) are highly valued and measured.

I am not going to go into the merits of this approach. I do have concerns that stem from the amount of social engineering required to set up such an appstore but I am happy to discuss and educate myself on how it might work.

However, I would like to highlight that there is a different approach that has nothing to do about engineering appstores but everything to do with building products. So without further adiue - here goes. This is how we are doing it:

1. It is not about Drupal - it is about solving a problem.

If you are building a Drupal product because Drupal is really cool, it is probably the wrong way to go about it. You should be building a product because there is a problem you believe you can solve in a manner that is attractive to others. Drupal happens to be the best technology (as far as you are concerned) to solve the problem.

We think all hotel websites should be built using Drupal. There are clear benefits to hotels owners in doing so. It empowers them to manage their own website, gives them access to the latest and greatest in terms of SEO technology and social web integration, gives them space to grow and the chance to take control of their online presence and frees them from relying on third-parties that cut into their profits.

2. Don't skim the surface - solve tough problems.

The monetization of DrupalRooms is based around offering services on top of an open-source distribution and booking management module. Hotels needs to plug in to a host of online services in order to get and manage clients. They need to worry about bookings, credit cards, channel management, yield, and run a hotel as well. We are building tools to help hotel owners solve these hard problems. As Paul Graham of YCombinator fame suggests - solve tough problems. The ones other people don't want to approach because they are nasty (not just from an engineering standpoint).

3. Open all the way - there is true power in being open.

You either believe that being open is more powerful than being closed or not. We happen to believe that open is best. Our product is developing in ways that I would have never envisioned. It is all down to all the people who are using it and suggesting features. I love it. It means I have to work less.

As I mentioned we will be selling services on top of the distribution and module. Even those services should be open, data should be free to take and the code or at least the processes should be available. No lock in. in the Drupal world do this really well. They offer a hosting service but also expose all the tools that would allow you to recreate it - the problem, however, is hard. So you might as well let them worry about it.

Drupal, by being open, allows us to plug in to a huge community. We want to copy Drupal and build a community around Drupal Rooms and also pay back to Drupal by growing Drupal adoption in the travel space.

4. Big Vision Vs Passive Income

We could simply sell the Rooms module for €20 - €30 a pop. I am sure many people would just pick it up. It would still be GPL, etc - we would just be charging to download the code and offer some basic support. We are increasingly being emailed (and people even call the office!) for Rooms-related support and we are not even out of alpha yet. It means there is a market. But do we want to simply make a few hundred euros a month or actually build something interesting.

We may not suceed but we are going for the latter.

And there you have it. Really looking forward to meeting and talking with others about all of this.

By the way, there are some exciting news around the corner for DrupalRooms - sign-up if you want to be updated.


Thanks, Ronald, good post.

I'm not sure whether there is a fundamental difference between Drupal Rooms and Portfolio, but if there is any, we need to sort that out and might need to find a terminology that helps to differentiate between the product "types."

One difference might be that Portfolio isn't and won't be backed by any kind of company, as it's a genuine community effort only. It still aims to deliver a fully-fledged product that solves a particular problem (just like Drupal Rooms), but there's no unique entity behind that effort that drives any kind of roadmap, provides support, hosting, or whatever else might be done by a commercially backed Drupal product.

Of course, not to mention that there are some larger discussions on already that try to dissect distributions from products in some way. In a nutshell, we additionally need to differentiate products that basically "lock you in." I.e., some distributions ship with a plethora of configuration, which is assumed to exist and persist as-is (in terms of maintenance updates), so changing and customizing that configuration will get you into trouble down the line. Open Atrium might be a good example for that.

On top of that, there needs to be a clear and intuitive separation between distributions that happen to contain any kind of hacks or patches, since that inherently means that you're running non-standard software that potentially has significantly diverged from its original, so it can and would be very wrong to assume that the software you're using is still fully compatible with its original, and thus, fully compatible with other modules/projects that might integrate with it. Therefore, any kind of code changes consequently imply an even deeper lock-in into a product.

Lastly, we need to discuss whether it is appropriate for any Drupal-based product to use "Drupal" in its name (as in "Drupal Rooms"/"Drupal Commons"/"Drupal Gardens" vs. "Portfolio"/"Open Atrium"/"Pressflow"), and if so, under which conditions that should be the case. I don't know any of Drupal Rooms' code, so I can't comment on that. However, as an outsider, I'd most probably expect that any kind of product with "Drupal" in its name is still Drupal core + contributed projects in their original and unmodified form, and because it's Drupal, I can do, change, and customize whatever I want with it, without running into configuration or maintenance update problems down the line.

See, a lot to discuss! :)

Submitted by Ronald Ashri on

Definitely a lot of to discuss but I just wanted to touch on the name issue.

Drupal Rooms is only ever going to be an open source distribution - will be the home of an open source solution and hopefully a community around it. As such it is similar to Drupal Commerce or, I suppose, Drupal Commons. We felt, therefore, that we followed the Drupal trademark guidelines and could use Drupal.

To put it even more bluntly we are never going to say "Buy Drupal Rooms for $20, now!" :-)
We will be saying: "Oh. you have Drupal Rooms, smashing. Are you interested in this other stuff over here that works with it?" or "You want us to install Drupal Rooms for you, well that'll be... ".

Part of being open is also not locking people in - especially not via confusion and obfuscation. DrupalRooms is a Drupal Distribution that any drupal dev should feel right at home with.

Haven't heard of Portfolio before - is there a link somewhere (searching for Drupal+Portofolio brings up all the portfolio pages of drupal shops.).

Submitted by Olen AGreenspan (not verified) on

Decent content. I will use some of this in my facebook account, will that be okay ?
Love to read this type of posts. Thanks a lot for posting it. Keep posting this type of stuff.

Great share. I need to admit I did not actually know there had been these shortcuts prior to. thanks for this really informative post.

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
By submitting this form, you accept the Mollom privacy policy.