Proprietary Social Business Software and Its Dirty Little Secrets

I love it when, for the third time in the past week, we get off the phone with a customer of our Social Business Software (SBS) competitor, Jive Software, and we hear that they are playing the same games that Enterprise software companies have played for the last thirty years:

- Everything is a "customization"
- Customizations cost lots of money
- Organizations need to rely on the company or its partners to perform customizations
- The (already) proprietary instance of the software becomes to customized, it costs even more when it comes time to migrate to a new release
- Repeat and start the vicious cycle all over again

I also love it when these organizations talk about the "total cost of ownership" of an Open Source solution being higher, due to exorbitant professional services fees needed to get an Open Source platform implemented and deployed. Guess what? We heard from one customer today that the comparative cost to upgrade and "customize" their current SBS platform was nearly THREE TIMES the cost of implementing a brand new, shiny Social Business site using Drupal Commons. Even better, when they need to add features to their new Drupal Commons community site, in many cases they won't need to pay a dime because there are thousands of freely available modules available for prime time usage via Drupal.org.

Drupal is quickly becoming to organizations like Jive what JBOSS was to BEA or what MySql was to Oracle (before Oracle threw in the towel and bought the company). We will appear on the scene from the bottom up, sideways, and eventually from the top down - and soon, we'll be competing head to head in not 2 out of every 10 deals, but 7 out of every 10 Social Business Software deals - and we'll win our fair share.

We'll be announcing some very exciting Drupal Commons wins over the coming weeks on Acquia.com and via Dries' blog. Watch this space...

Comments

Posted on by Juliee (not verified).

honestly speaking i dont like durpal i guess wordpress,dolphin,joomla is still the best and at the top ranks.

Posted on by ngmaloney (not verified).

Care to actually list some valid criticisms with "Durpal" in comparison to the other CMS's you mention?

Posted on by Tim Bertrand.

Julie - to each their own.....

Thanks,

Tim B.

PS - also, it is "Drupal", vs. "Durpal."

Posted on by farnoud (not verified).

Hope you upgrade Drupal Common to D7 soon enough

Posted on by Jay Batson.

Hi, Farnoud -

Drupal Commons has a very large number of community contributed modules in it, so for the most part we're dependent on when the maintainers of those modules have a production-level release of their modules for D7. You can find a list of all the modules in Commons on the community site for Commons, along with the D7 status of those modules.

My gut-level guess says we won't see the last of those modules upgraded to D7 until after mid-summer. Once we start to see a critical mass done, we'll get started on the D7 move, and try to pitch in and fill any remaining incomplete modules.

One key element is that Organic Groups has had a complete rewrite for D7. We haven't yet tested to see how much has changed, or how much work would need done. We're thinking it all looks ok, but that's a big dependency.

Posted on by LeeHunter (not verified).

It would be nice to learn how Drupal might be integrated with a traditional JSR-168 enterprise portal environment.

Posted on by cpliakas (not verified).

Hi Lee.

Would you care to elaborate on what the nature of the integration might be? For example, are you trying to use Drupal to create a portlet? Is is sitting outside the portal and interacting with the applications via web services? Any additional information you could provide would help with your inquiry.

Thanks!
Chris

Posted on by LeeHunter (not verified).

At this point in time, I'm not sure because the organization I work with hasn't actually made a decision about acquiring a portal, much less worked out the various integration scenarios, but there's an assumption, at least in some parts, that we will have an internal web portal in the forseeable future.

So when the subject of web technologies comes up, there are people who say that we should only look at Java products that comply with portal standards. I'd love to hear of some cases where organizations are successfully using Drupal and a portal together successfully.

In other words, we might never actually get around to getting the portal, but just the thought that we *might* creates a degree of uncertainty that raises a barrier to adopting open source products like Drupal for other work.

Posted on by Jay Batson.

Leaving aside the actual function of Standards, the underlying need for standards arises from the need to solve specific problems. Drupal / open source solves the same problems - just in a different way.

  1. Code re-use for enhancing functionality. The JSR's let you plug in extensions to a portlet container to add functionality. Drupal solves this through "de-facto" (vs. defined) standards - there are already over 7,000+ plug-in modules to extend Drupal. How many portlets can you find? Drupal solves the problem through success, not arbitrary standards.
  2. Avoiding lock-in (of data). Portlets attempt to make sure the portlet can get at underlying data in flexible ways to avoid locking owners away from their data. Drupal solves this problem by not hiding the data in the first place. Since Drupal is open source, and its data all lives in an open database, there's no lock-in problem to solve.

There are more reasons, but demonstrates the way to think about the question; look at the business problems portlets are trying to solve, and see how Drupal solves the same problem. For the most part, you'll find that open source Drupal will trump the Portlet-standards approach, both in function and result.

(You can also argue that the folks pushing to look only at Java products with standards are Java bigots. But this is a wrong approach to take; making a personal judgement like that doesn't win - even though it's true. :-)

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.

Filtered HTML

  • Use [acphone_sales], [acphone_sales_text], [acphone_support], [acphone_international], [acphone_devcloud], [acphone_extra1] and [acphone_extra2] as placeholders for Acquia phone numbers. Add class "acquia-phones-link" to wrapper element to make number a link.
  • To post pieces of code, surround them with <code>...</code> tags. For PHP code, you can use <?php ... ?>, which will also colour it based on syntax.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <h4> <h5> <h2> <img>
  • Lines and paragraphs break automatically.
By submitting this form, you accept the Mollom privacy policy.