Founded | 1996 San Francisco, California, U.S. |
---|---|
Founder | Glenn Kelman |
Defunct | October 20, 2005 |
Plumtree Software is a former software company founded in 1996 by product managers and engineers from Oracle and Informix with funding from Sequoia Capital. The company was a pioneer of extending the portal concept popularized by Yahoo! from the web to enterprise computing. BEA Systems acquired Plumtree on October 20, 2005, and Oracle subsequently acquired BEA. Plumtree's former portal product continues as part of Oracle's product line.
Plumtree can be used to deploy both Java and .Net portlets on the same page. The Plumtree Corporate Portal, Plumtree's flagship product, began as a Yahoo!-like directory for indexing and organizing content from file systems, Web sites, document databases and groupware repositories, creating a rich knowledge management system for enterprise information. In 1999, the company introduced the idea of self-service personalization via portlets, originally termed "gadgets" by Plumtree, the modular services that users could assemble in their own portal pages. Portlets became prized for surfacing popular services from complex corporate systems to a broad audience. In 2000, Plumtree added features to support communities, which allowed users to build pages as workspaces for a team, resource centers for a business unit, service centers for customers or partners.
As the range of resources integrated within Plumtree’s system grew, the company was forced to re-imagine the architecture of a Web application, using Internet protocols to go beyond a model limited to one type of application server or one language.
Internet protocols offered a new level of openness: rather than arguing over which application server or language was more open, Plumtree’s system could support many application servers, many languages. Plumtree called this level of openness “radical openness.”
Plumtree’s experience with portlets taught the company that running all portal services locally, on the same application server as the portal, was impractical: local portlets were limited to one language and one application server, but every large organization supported more than one language and one type of application server.
Moreover, when the portlets ran on the same machine as the portal, each portlet could introduce faults or conflicts in the entire system. Whenever a portlet failed, the portal could fail, and identifying the fault involved removing portlets from the portal one portlet at a time.