When I blogged about Webdetails joining Pentaho, I mention that a lot of the community work I was going to do would be on the inside of the organization, working to come up with better models to allow and motivate community users to work with and enhance our tools. And it's never enough to say that my definition of community includes both EE and CE users.
What I'm presenting now was a collaborative work from several areas of Pentaho - from PM to Sales, from Support to Engineering - and was approved last week by Doug Johnson, Pentaho's COO / CFO.
Call me a day dreamer - I do like to aim high - but I believe this is going to be an important milestone in Pentaho's history! :)
Project Maturity Classification
A "closed-model company" only has to worry about what happens in-house; Product Management defines the product roadmap, Engineering builds and fixes the product and Support is the interface with paying customers.
In an open source company, things are not as top-down; There are both paying and non-paying users, anyone can contribute to the code and people on the community may build projects to extend/plug-in or embed into the platform that effectively affect the roadmap. The Ctools are a great example.
The Project Maturity Classification model tries to address some of these roadblocks, embracing (and promoting!) the fact that not everything is done in-house.
![]()
The model consists of two parallel “lanes”: Lane 1 = Community Lane for Community and customer-sponsored projects; Lane 2 =Customer Lane for projects which are part of the official Pentaho offering. Why create a maturity classification system with two lanes?
Community Lane
![]()
Projects in the Community Lane are created by contributors in the Community and exposed through the Pentaho Marketplace. The Community Lane will also be used for projects created by Pentaho Consulting or Engineering Services, in which case they will be managed so they do not conflict with the long-term architecture and functionality planned in the Pentaho product roadmap
Customer Lane
![]()
Always overseen by PM and Engineering, projects in the Customer Lane can either start as customer-sponsored initiatives or as projects developed in the Community Lane that create value for Pentaho subscription customers. Pentaho will provide official support based on current support policies to projects on the Customer Lane
Next steps
This is only the beginning - now we have to act on it. Highest priority on my work queue is to change the Pentaho Marketplace to reflect this classifications and keep working both internally and with the Community to see if we can get execute on these concepts and get more and better contributions that will certainly get the product to the next level!
More...
What I'm presenting now was a collaborative work from several areas of Pentaho - from PM to Sales, from Support to Engineering - and was approved last week by Doug Johnson, Pentaho's COO / CFO.
Call me a day dreamer - I do like to aim high - but I believe this is going to be an important milestone in Pentaho's history! :)
Project Maturity Classification
A "closed-model company" only has to worry about what happens in-house; Product Management defines the product roadmap, Engineering builds and fixes the product and Support is the interface with paying customers.
In an open source company, things are not as top-down; There are both paying and non-paying users, anyone can contribute to the code and people on the community may build projects to extend/plug-in or embed into the platform that effectively affect the roadmap. The Ctools are a great example.
The Project Maturity Classification model tries to address some of these roadblocks, embracing (and promoting!) the fact that not everything is done in-house.
The model consists of two parallel “lanes”: Lane 1 = Community Lane for Community and customer-sponsored projects; Lane 2 =Customer Lane for projects which are part of the official Pentaho offering. Why create a maturity classification system with two lanes?
- Providing users with guidance on the maturity of plugins they use with the Pentaho platform. This is a natural complement to the Pentaho Marketplace
- Clearly communicating with customers what is supported by Pentaho, what is not suppoert, and what is the level of support associated with each entry
- Promoting innovation (regardless if it's an internal customer-driven initiative or a community-led effort) with clear integration paths with the Customer Lane. This will enable everyone to move faster on some areas, adopting what's popular and ditching what isn't
- Clarifying to prospects / customers/ community/ etc how Pentaho leverages it's Open Source roots and how that puts us to a huge advantage compared to the rest of the competition
Community Lane
Projects in the Community Lane are created by contributors in the Community and exposed through the Pentaho Marketplace. The Community Lane will also be used for projects created by Pentaho Consulting or Engineering Services, in which case they will be managed so they do not conflict with the long-term architecture and functionality planned in the Pentaho product roadmap
Customer Lane
Always overseen by PM and Engineering, projects in the Customer Lane can either start as customer-sponsored initiatives or as projects developed in the Community Lane that create value for Pentaho subscription customers. Pentaho will provide official support based on current support policies to projects on the Customer Lane
Next steps
This is only the beginning - now we have to act on it. Highest priority on my work queue is to change the Pentaho Marketplace to reflect this classifications and keep working both internally and with the Community to see if we can get execute on these concepts and get more and better contributions that will certainly get the product to the next level!
More...