RichFaces 3.2.0 was a huge step ahead. Dozen new components and feature from the top of the feature list were implemented. We dropped support for JSF 1.1 and started to use JSF features available only in JSF 1.2. After so big changes, the migration from 3.1.x to 3.2.0 was not so easy for many of end developers as it was previously. RichFaces 3.2.1 is dedicated to make this process easier. It will include the fixes for the problems reported by community after the 3.2.0GA release. RichFaces 3.2.1 is in QA stage right now (end of April). It going to be released at the middle of May. The question is about the strategy for the future development. RichFaces 3.0.0 has 18 components (plus a half of dozen in Ajax4jsf) when it became a JBoss RichFaces about one year ago. About 20 people were in the RichFaces team. Currently, RichFaces 3.2.0 has more than 80 components. Still the same 20 people are in the team. As far as we cannot expand the team, we need to have an optimal strategy how to use our resource effective developing the product in the future. Based on the feedback from the community (this Forum) and the RedHat/JBoss support team, we can  emphasize four possible major directions: [b]1. Developing new components[/b] to continuously extend the component set. We have already several highly-voted components at the "future" table, [url]http://wiki.jboss.org/auth/wiki/RichFacesFuture[/url] such as Rich Editor, dockPanel, Layout Components (i.e. several one in the set), treeTable, Confirmation Dialog, etc. Developing new components directly increase the capability of the library (that is certainly good), but also increases a cost of the further support and maintenance. The term cost here does not means money, but the components per resource ratio (as far as the number of resources is constant). More components are developed more time is required for the whole product lifecycle from the analyzing requirements to the  QA process. I.e. the timeframe between the releases should be increased (to reach the acceptable level of product quality) [b]2. Simplifying the development[/b] with JSF and RichFaces. This, also, includes the new features that are missing in the JSF as a framework, like Client-Side Validation. Based on the forum posts, we can say that permanently increase the number of people developing with RichFaces who have very limited knowledge of JSF. Simplifying the development is a goal for JBoss Seam framework. So, we will always have the intersections here. [b]3. Keeping RichFaces constantly stable[/b]. This means concentrating on the fixing bugs and enhancing already existing components rather than developing  new ones. This job also includes writing the automated unit and integration tests, testing in the wide number of possible environments and combination to prevent possible problems  end developers have using RichFaces. This option is opposite to #1, but still requires more time for QA phase to reach the main goal. [b]4. Making RichFaces modern and cool[/b]. This include catching and customizable look-n-feel with predefined set of "sexy skins", using effects during the interaction with components, keyword navigation, supporting browser history, using semantic-friendly layout and so on... Well, if you have only one component you can spend one to three weeks to reach the goal. Doing the same with about 60 components is a really huge amount of work (just try to multiply). The drawback here is possible broken a backward compatibility on the UI level (ie. you old application will not look exactly the same after upgrade). RichFaces is a Java [u]Server[/u] Faces components library. Instead of pure client side widget set like extjs and gwt, we do care about a lot of things in addition like state saving, lifecycle, data binding, ajax re-rendering and so on. It is again about the cost of new features. So, what is your suggestion? Pick one option that is more preferable for you. Of course, [u]picking one, does not mean dropping the rest[/u]. It is just about priorities and the balance between them.