At the end of WOWODC 2015, there has been a discussion about the current state of Wonder and it’s future. I try below to summarize this discussion, but I did not take notes, and this is what I remembered from it, so this is by no means an « official » or comprehensive summary. Please feel free to add elements and correct me if my report is biased.
An observation that can easily be made, and by which the discussion started, is that Wonder is in a stale state. There are less and less pull requests, and even fewer commits. According to the participants, there are several reasons for this. The first one is that some of the most active, talented contributors are either no longer doing WebObjects development, or are working for/at Apple and can no longer contribute. The second reason might be that some contributors have been disappointed by the fact that their pull requests have been ignored (neither reviewed nor committed), perhaps due to lack of time / knowledge from committers. The third reason, which has been strongly emphasized during discussion, is that some of the current maintainers of Wonder may have been over-conservative, and reluctant to make changes (in fear that changes “might break something”). Thus pull requests have not been accepted, and contributors have been deterred from making other pull requests. More generally perhaps, given the strong uncertainty around Wonder future, some companies, institutions, or developers, have adopted “individual strategies” (by opposition to collective strategies): they work on their own fork of Wonder, or subclass Wonder classes in their own code to add functionality or fix bugs. Individual strategies are not bad per se, but they often lead to suboptimal situations (redundant resources allocated to solve the same problem).
The first solution proposed during the discussion is to call for pull requests (“guys, make more pull requests please!”) and make a promise that they will be more actively reviewed (and maybe committed). Sure this is a good step, but, given the situation, this probably won’t be enough…
Another proposal would be to almost automatically commit, after a certain period of time, pull requests that have not been reviewed and pulled.
The previous strategy seems a bit too risky to some of the attendees, and a proposal has been made to make a condition that, to be automatically accepted (if not reviewed), a pull request should contain unit tests. But according to other attendees, this condition will be a blocker (not exactly what we need right now), and will not be very useful and won’t prevent undesirable side-effects, given the fact that Wonder has very few tests implemented.
As an alternative, a condition was proposed that at least, pull requests should be well documented, so that reviewers get a good grasp at what the problem at hand is and why that solution is proposed.
There has been a large consensus that the maintainers of Wonder must be less prudent and conservative about proposed code changes. The first reason for this is that Wonder developer’s community is not composed of teenagers but of professional programmers that have little chances to make very silly / dangerous pull requests. The second reason is that now that Wonder releases are versioned, it is easy for those who are more risk-adverse to work on versions that have proven stable.
A point has been made that Wonder should be in the hands of the actors that are actively using it (and enhancing it), and not in the hands of actors that no longer use it. That should entail that each (major? willing?) company / institution actively developing with Wonder should have at least one contributor with commit rights. That could be an incentive to make pull requests, and a signal that the community is decided to change the current state of things and wants to share the responsibilities about our “public good” (Wonder is a public good). Normally, in an active open-source project, contributors gain commit rights by the number and the quality of their pull requests. But Wonder is no longer an active project, and therefore, the grant of commit rights might serve the purpose of making it active again.
Here is what I remember right now, and I just want to add that the discussion was very friendly, open, and constructive.
JPM