Home / Comment permalink

Roadmap, or Roadblock?

I continually marvel at how much better the open source world works than the old proprietary software software world.

Yesterday I encountered an amazingly good illustration. I was discussing Drupal Commons with a team from a large, household-name enterprise that is planning a social business site. And boy, they had lots of questions!

Their business unit leaders, their IT staff, and their web designers all had some version of “Can Drupal Commons do (X)?”

Happily, I could answer either:

  1. Yes, X is built-in to Drupal Commons already;
  2. X can be had by merely installing an existing Drupal module available on drupal.org; or
  3. There’s no pre-built module, but you can have X quickly via adding a bit of custom code to the open source base.

I felt confident that a Drupal-based solution for this customer will satisfy nearly every requirement they had with either 1, 2, or 3.

But the interesting part is this: When we asked whether the competing vendors had feature X available, we heard (more than once):

“Well, it’s something (proprietary vendor) said is on their roadmap. We’ve heard it’s in their next release, but we’re not sure about that.”

And bang - it hit me: the proprietary vendor's roadmap was a roadblock for the customer at that moment, despite the bright future that the roadmap supposedly leads to. This sounded so familiar that I had to stifle a laugh; in my past I’ve worked many years in companies that sold proprietary software, and we always needed a product roadmap response when we lacked a feature. And the list of roadmap features that never got implemented - and thus blocked a customer’s business - would fill my laptop’s hard drive today.

My happy realization at that moment was that I will never need a Roadmap response in the open source (Drupal) world. If a customer absolutely positively needs something, the only delay in getting it is the time it takes to get a programmer to implement it - either directly from Acquia, or from the staggeringly vast population of open source Drupal programmers.

Wow. What a difference! No roadmap (roadblock) promise required. No roadblocks for customers, ever again.

The other thing that hit me was that in the proprietary software world, the roadmap is always influenced by the biggest customer deal in the sales pipeline. If a big enough check comes in, Customer 2 will promptly delay the release date of Customer 1’s most-desired, and already-promised roadmap item. In a proprietary software company, the roadmap is a BIFO queue: Biggest In, First Out. Tough luck for you if you’re not the Biggest.

Can you guess what I’m saying next? This is totally not the case in the open source world.

And again: Wow. What a difference! No competition for highest-priority on the roadmap.

This was apparent in spades in our customer visit yesterday; we can deliver exactly what this customer wants, and do it now - without making the customer wait for some future release of a proprietary program or API. Plus, the fact that I could answer “There’s a module for that“ was an amazing demonstration the value of using open source: the breadth of available plug-ins amazingly accelerates the delivery of their business objectives.

This customer provided a textbook demonstration of the major advantage of using open source Drupal Commons instead of a proprietary social business software solution: The Freedom from technology limitations - and roadmapsblocks.


Posted on by fuerst (not verified).

“There’s a module for that“ sounds good but should not lead to the assumption it will satisfy the customers needs immediately. Moreoften I find a module just being the start for a solution not the solution itself. That's fine for prototyping but the adaption to special use cases is not as simple as installing a module.

Posted on by Jay Batson.

It can certainly happen that a module is only a starting place. We occasionally found that to be the case when assembling Drupal Commons.

But much more frequently, we found that the modules "just worked" out of the box. They required some configuration, some occasional theming, and - voila.

And even in those cases where "some adaptation was required," what we got from the existing module was way beyond prototype; it was most of the solution, and we merely needed to add a few lines of code to adapt it to how Commons needed it to work. Generally, the gap between what the module provided and what we wanted was pretty darn small - much smaller than starting from scratch.

Posted on by fuerst (not verified).

Sure, many modules are freeing you from doing the basic stuff. Still I think the modifications needed to get what the customer wants are just not what the phrase "There is a module for that" suggest. Your mileage may vary..

Posted on by blainelang (not verified).

Great observation Jay and very true. Often clients don't yet really know what the final solution will ultimately be. Using open source gives them an in-expensive and flexible way to explore their ideas. In a large enterprise environment, there are a lot of potential requirements that will influence a spec and sometimes their spec is developed after talking to vendors and getting pitched the 101 product features of which they need only 50 but will have to pay for the 101. They may also need to tweak some of the features and as you noted add a couple that are not in the product. Open source gives them that freedom and is often the case with Drupal, that idea they need - well, it was just posted as a new module yesterday.

Posted on by Boris Mann (not verified).

Great post, Jay.

One thing I would like to expand on is the possibility that Customer 1 and Customer 2 both want the same functionality, they can work together and get it for half the cost (or twice the features :P).

That's the next revelation that I'd like to see practiced more heavily in the open source world.

Posted on by Jay Batson.

Boris - I think there's a pony in there somewhere.

We've seen a lot of this over time - requests coming from various customers for the same thing. And we've even had customers approach us with the same idea you just mentioned.

The tricky part has been timing. We haven't yet had two customers come looking for the same thing during the same sales cycle for each. Usually, they're separated by weeks or months - an eternity in the mind of those customers who have business deadlines they need to meet now. So the customer typically will cut the feature, or redefine it to a more affordable level.

The other slightly tricky part has been slight variations in the ultimate functionality desired. Fortunately, good engineering can usually figure out how to make a module flexible enough through configuration to meet several purposes. Usually - but not always.

So I'd love to see your idea grow - but we've got to sort out the timing problem, and find features where the differences are at a configuration level. I wonder if there's a more enterprise-like variant of the Chip-In model that could be thought up..?

Posted on by sun (not verified).

Audience size matters. I think that Boris merely refers to bounties and reverse bounties, which are occasionally used throughout the Drupal community already. But there's no real, not even semi-formal environment in which those are performed.

If bounties would be a more official concept on drupal.org, then a much larger audience would be able to participate, in turn, vastly increasing the chance for various multiple people being interested in the same solution.

Formalizing the concept and introducing bounties as official content and activity on drupal.org would additionally allow to review suggested resolution attempts, prior to potentially wasting time and energy. Also moving yet more topics from the (IMHO bloated, obsolete and bogus concept of) drupal.org forums into structured data that we can display at the proper places, at the right time. For example, when displaying project search results. :)

I'd say it needs less "enterprise", but more "community".

Daniel F. Kudwien
unleashed mind

Posted on by Jay Batson.

Dries & I have talked before about a more formalized d.o approach to bounties before. And I have mixed feelings about it. (I'll let him share his thoughts, should he see this discussion.)

On one hand, what you suggest would have exactly the results you suggest - there's a good chance it could have a good impact; Drupal's ChipIn history should suggest "in general" that this works.

On the other hand, it raises a mixed-motivation issue. First, I don't think we want to make feature-development in Drupal hostage to people holding out for a bounty to fix something. Introducing a too-extensive precedent in the project for getting paid to advance Drupal is a bad thing.

I also have a secondary concern that modules developed without a specific customer driving requirements often seem to me a little bit "ivory tower"; they exhibit lack of awareness of the requirements that accompany real-world deployment.

And to be honest, it's my belief that the process of having Drupal consulting shops build something for a real customer, then contributing that code back -- is what has driven Drupal's success, not bounties. (At least in the Contrib module universe.)

So on balance, I've tended towards a conclusion that 1-3 paying customers, with specific requirements (to keep the module focused), who bite off a big chunk of an apple to do a "complete" thing, then contribute the code back, are better than formalized bounties.

To me, the key would be to see if there's a way to move from 1 to 2-3 - so that the work is a) funded, and b) focused. But again, timing is the issue.

But that's just my personal opinion (not Acquia's..).

Posted on by adixon (not verified).

Thanks for this comment. I've always been a bit vague about what I don't like about the bounty model, and your thoughts are helpful to me in thinking about it.

To expand that a bit:

The process of exploring user requirements and then converting it into a technical specification is one of those things that is much easier to say than to do, and sometimes it probably shouldn't even be done. The point is that "user requirements" are a language that is very different from a technical specification of what a module does. Sometimes they mesh wonderfully (hehe, e.g. when user requirements are defined in terms of existing technical methods), but usually they don't, in which case they will always be in some kind of creative opposition with each other. People who don't actually do coding sometimes spend way too much time deciding what coders should do, in my experience, when it should optimally be a conversation between the user requirements and the technical specification (yes, and coders deciding what the non-coders will experience is a similar disaster, but that's exactly the same point: it has to be a conversation).

So the idea that you can define a nice round technical spec. out of a set of user requirements, and then shop it around to a developer, is a nice illusion, but one that usually comes to grief in my experience. Sure, it'll work sometimes, but setting it up as any kind of standard practice sounds like we're going down the crazy road of RFPs as commodities to be bought and sold (and surely we've learned from that!).