Wicket Meta

Overview

Wicket NG is a proposal for a version of Wicket that is less encumbered by concerns of compatibility with previous versions. This document attempts to open a dialog within the community about concrete features that might go into such a version, including why such features need to have the license to make changes (as well as search for situations where they don't). Once such a baseline proposition is agreed to, the overall total cost (both from development resources and end-user developer resource costs) can be better quantified.

Prior to getting into that, we need to address elements bounding the problems the solutions that can be considered. As it stands, there's been significant resistance on IRC to considering the start of a major release (i.e. 2.x or 3.x).

History

By measure of longevity, Wicket has had a very successful life. Within Java-based frameworks, Wicket has had a longer life without a major API change of any of the major web development frameworks.

Competitive Landscape - Struts

Conceived in 2000, four years before Wicket, Struts pioneered open source MVC development. While some would argue that Struts 2 has evolved into JSF, they are in reality very different frameworks. Even so, if JSF were to be considered to be "Struts 3", it still goes to say that Struts has now had two major evolutions of the framework where Wicket has had none.

Competitive Landscape - Spring WebMVC Framework

As a relative latecomer in comparison to Struts, Spring WebMVC had the benefit of learning from the mistakes made in Struts and evolving with less architectural thrash. In general, the web framework is heavily dependent on the Spring container itself, so it is not suitable for some environments. Evolution of WebMVC has been minimal, in large part because much of the functionality (such as Spring Security) has been developed as components that can be used in any deployment of the Spring container. Like Struts, the simplicity of Spring WebMVC is directly linked to the lack of comprehensive session management.

Competitive Landscape - Tapestry

In a way, Tapestry can be considered a very close relative to Wicket, they are both pioneering component-oriented Java web frameworks. The history of Tapestry doesn't bear much repeating here for various reasons, but there is a universal concern within Wicket of avoiding the major API overhauls that happened within a very short timeframe on Tapestry. The Wicket project has demonstrated that "slow and steady wins the race" for end user hearts and minds, but to some degree, this writer believes that it is possible to have "too much of a good thing". This writer actually started with Tapestry and came over to Wicket as after seeing the promise of the development paradigm but having spent too much time dealing with incompatible upgrades.

Wicket

In the evolution of Wicket, the closest thing that it has had to a major API overhaul was with the aborted 2.0 line, where attempts were made at doing constructor-based parameter injection. With exceptional effort and occasional reference to both the 2.0 line and Tapestry's history, Wicket has evolved in a manner that has avoided major change though out it's history.

Roots of Change

Before getting into "what" to change, it is valuable to agree on the premise of "why" to change.

Value Propositions

The effectiveness of a framework project over time is generally a balance between the stability of the APIs that it provides in combination with it's ability to track new features available in an emerging internet over time. For instance, the common use of OAuth is a space that would be very welcome for most pioneering application developers.

But if including such a feature required either breaking APIs, extensive work to avoid breaking APIs, or not implementing the feature at all, hard choices must be made. Without the feature, developers may decide to migrate to another framework that offers such features on a regular basis.

In turn, this "other framework" may be able to continue offering features in a manner that avoids API changes, or it may not. Will this developer care? Since every application is different and no developer has the same demands on the public API of the framework they use, there is no way to know whether they will be affected by a succession of changes. Each framework ends up with a collection of developers that, for better or worse, have found the framework they use is "right" for them. But it doesn't mean they aren't constantly aware of changes in the market (some more than others). And when they leave, they rarely do so in despair, but just simply in an interest to "try something new".

This relationship is no different than any other service provider relationship. The value received by a framework user is the sum of the usable features that it provides in a generic way, the cost is the effort required to both understand these features, implement them, and keep up with the API changes that are required. If it were a cell phone provider, the value would be the ability to communicate with the maximum number of people for the least amount of legal tender. In sum, the value proposition.

Even with comparatively limitless resources for some companies, getting the customer value proposition exact is still impossible. There are too many variables to do any such quantitative analysis.

From the perspective of a framework developer, the a slightly different value proposition is at work. In this case, participating in the development of a valuable framework provides a certain amount of personal satisfaction in a job well done (potentially measured by the number of loyal users and like-minded friends), as well as a certain aspect of professional mobility that is created by their consistently productive efforts over time. Like most humans, framework developers generally wish to maximize this return for a unit of work invested.

Need for Features

It is against these sometimes conflicting needs that a this author (and others) feel it is time for a major release, one with a preference for new features than the maintenance of backwards compatibility.

After informally talking to a number of users, the general feeling is that Wicket is being unnecessarily restrained by an unquantifiable need for maximum backward compatibility, which in light of constant available core developer resources, comes at a cost of these features – features that are now incumbent on each developer to develop on their own.

Some core developers have noted that there is very little demand for some of these features, but such is the case with any feature that does not exist. Most users are grateful for what they do have rather than outspoken about what does not exist and they are not willing to implement themselves. And as has been pointed out, developers generally leave as quietly as they came, more curious about the new than leaving under a cloud. Life is easier that way for everyone, but the users are still gone. It doesn't have to be that way.

User Churn vs. Resource Availability

What of the project if people are leaving? As critical mass starts to erode, the difficulty of finding new users starts to grow. This is a self-fulfilling prophecy as core developers find less autonomy through outside work prospects, forcing demands of day jobs to take an increasing portion of their ability to contribute. Prospects for everyone erode.

On the other hand, imagine if a framework suddenly required very little effort (in terms relative to other frameworks) to develop a professional website? This would certainly attract new users!

Is it worth the cost to attract those new users at the cost of existing loyalties? Of course not! But most successful developers are mature enough to know that if they don't need the features of a new version, there's no sense in upgrading. They have no expectation of support on earlier versions, but if the community continues to exist for said version, the community will continue to support it by nature of it's popularity.

Both groups are served in this manner, and while the community may be somewhat split by somewhat parallel versions, the community as a whole grows, allowing for this growth to become sustainable. In terms of economics, this would be an entirely Keynesian perspective. We wish to improve the circular flow of energy and effort in the Wicket ecosystem, but there needs to be a primer, a booster shot of sorts.

Finding a Way Forward

It is a very concerning problem for any project to lose key developers. It's especially a concern if these key developers are also founders. A recent discussion on IRC about the core developer pool showed that in the month prior to writing, the majority of the commits were made by two developers, with two others making a relatively small number of commits. This seems to be an unfair burden placed on these developers.

As for developers that want to contribute and do so with maximal quality, the project must find a way to take the path of least resistance. As an example, in the same IRC conversation that was previously mentioned, an aversion was noted to having too many modules. It was also noted that the company that the commenter worked for felt that "building individual releases of our modules is not our core business" and admitted that their process was quite different than most development companies. In almost exact turnabout from the previous paragraph, this writer believes that an implicit requirement of supporting such environments is an unfair burden on the rest of the community.

Clearly, compromise is going to be necessary for these disparate ideas to find fair and equal footing when viewed from the eyes of merit. What makes a meritocracy work? These are core concepts that the community needs to agree on before the concept of the Apache Way can be used in a manner that provides any benefit.

Summary

This document is currently a draft and should be considered as such. There are no proposals, it's just a bunch of hot air. Please wait for the rest of it before getting any panties bunched up over it.