“We call this re-imagining Radical Openness. Radical Openness is our strategy to offer both J2EE and .NET versions of our entire application management framework, new points of integration for synchronizing the Enterprise Web environment with systems of record as well as desktop tools, and the ability to embed Enterprise Web services in any Web application,” Kunze continued. “Ultimately, we believe the way applications are being developed is fundamentally changing, and that with the Enterprise Web, applications can be developed in greater volumes, at lower cost, and on a wider variety of platforms than ever before.” –John Kunze, CEO, Plumtree, Inc. (excerpted from a 2003 press release).
bdg‘s response to this is that in some ways it is and in some ways it isn’t.
Plumtree is Open:
- It runs on Windows (.NET or Java) or Solaris (Java)
- It can embed portlets from anything that speaks HTTP(S)
- It uses SOAP over HTTP for Crawlers, Authentication, Profiling and Search
- It runs on SQL Server or Oracle
Plumtree isn’t Open:
- It only runs on only Windows and Solaris, not AIX, HP-UX, Linux, or any other *nix
- It’s entire codebase, though highly pluggable and configurable, is proprietary
- It uses proprietary headers (CSP, which stands for Content Server Protocol, no relation to Plumtree’s Content Server, don’t ask 🙂 to communicate information to and from portlets*
- It only runs on SQL Server and Oracle, not MySQL or any other RDBMS
*Plumtree does support both WSRP and JSR-168 through plug-ins, though they limit functionality to some degree (more on this later).
I should preface all of this by saying that I still believe Plumtree is far and away the “best” portal solution for most mid- to large-size corporate intranets and even extranets for a whole host of reasons. I mean really, why would I bet my company on it if I didn’t?
However, it’s easy to confuse “open” with “pluggable” when they are in fact very different. When I hear things like, “my web service is written in Ruby on Rails, but .NET, Java and PHP clients use it all the time,” then I think “open.” (And no, if you’re wondering, I’ve never actually heard that, not even from Dave Thomas.) When I hear, “sure, you can replace the page navigation in my presentation layer, but only if do it with Tapestry” then I think “pluggable.”
Plumtree’s UI is pluggable; their WS/PRC server, EDK, CWS, AWS/PWS and SWS architectures are open; and their Portlets are, well, a little of both: they’re very open in that you can write them in anything that speaks HTTP(S), but only if you do it with their proprietary headers, but then, well, you can use JSR-168 or WSRP to get around that, but then, well, you can’t get all the functionality like Adaptive Portlets . . . .
When it comes to Plumtree’s Portlets (or Gadgets as they used to be called), it almost sounds like I’m arguing with myself.
In summary, if you’re looking for a proprietary product that’s built on some open standards that you can extend using open standards (sometimes) but that only runs on certain platforms, well, then Plumtree is for you.
While I’m not in the business of making excuses for Plumtree, I must say that every time a company with a proprietary enterprise software product needs to support a new OS or browser or database or “thingy” they need to run that combination through a testing matrix that grows exponentially each time you add a new “thingy” to it. That is a royal pain in the proverbial backside.
The complexity of the testing matrix alone is a great argument for open sourcing everything. (And yes, I understand that open and open source are not the same thing.) While I do see merit in commercial, proprietary software, I assure you that if Plumtree’s code base were open source it would already be running wild on Linux. Why? Because I would have compiled it myself. 🙂
2 replies on “Is Plumtree an “open” platform?”
Well your take on Plumtree and Linux would change shortly as 6.0 is going to support Linux as well.
I know . . . and I can’t wait! Word on the street is that they’re going to start by supporting SUSE, but I’m not going to dally in trying it on my small army of RedHat workstations, even if it’s not officially supported. I’ve already got the 5.0J version running on Solaris boxes in my home office/lab, but the advent of the Linux version means that I can run it on almost anything, and that’s very exciting.