Ok, the title is misleading. I think that Project Coin is doing great work. I just loved my subsection title so much that I couldn't resist. :-) Besides, it made you look. If only I can get you to read all of this. :-D
In their interview with Joe Darcy and Alex Buckley, the Java Posse raised some very interesting points about the evolution of the Java language, the JVM, and the Java language platform (Yes, I do think that we should start thinking in terms of a Java language platform, but that is another post). However, they missed some key frustrations that are effecting the participation in the open jdk. There appears to be some disappointment that there has not been more uptake of work on the JVM. However, I think this can be isolated to three specific issues. There is no mechanism for participation in the decision process for what language features are or are not included in the in the Java language. There appears to be a very Sun centric view of available resources. And, there is no mechanism for carving up the work on what appears to be significant portions of work to implement and test language proposals. PARTICIPATION Project Coin was a great start. It was billed as a mechanism to get your small language change ideas into the hands of the decision makers. I think that there was a severe mis marketing there, as it is clear from the comments that the intention was not to gather the ideas, but to gather prototypes for the implementation of ideas. Even at that, there was frustration with how the Project Coin leaders (Joe and Alex?) arrived at their choices. Clearly they were difficult decisions and they did the best they could in their choices and to explain their decisions. They can't make everyone happy. I think, however, the approach is flawed. First, the mis-marketing could have been solved by some simple web site redesign. The web site should go through two phases. The first, should be a process where the ideas are listed. This could be community driven or project team driven. However, it should clearly show (with a separation of lists) the ideas that are under consideration and those that are not. All ideas should start as proposed, but not under consideration. The second phase would be the work phase. This phase would provide the mechanism to move the idea from proposed state to the under consideration state. In order to do this, the appropriate documentation, prototype implementation, and test cases would need to be provided. For those features where the community was not willing to do the work to implement is, this should provide a clear delineation of why they were not considered. It would also make it easier for the onlookers to take up the cause and try to augment the ideas. In this latest process, once an idea was proposed it felt like there was an expectation that the proposer was responsible for the implementation work. As a result, it didn't feel like I (or the other onlookers) could participate in furthering that idea. It was there idea. In fact, it seemed to foster more of a competitive environment (as opposed to cooperative). Second, the decision process. There are two models for difficult decisions. You either use a dictatorship or a democracy. In this case, Project Coin tried to act like a democracy, but ultimately made their decisions like a benevolent dictator. As Miyagi said, left side of road ok...right side road, ok...middle of road, get quashed. This dichotomy is confusing. Joe and Alex said in their interview, "if you have a funnel a mile wide and an inch deep, how do you choose what goes through?" Well, politics 101 is that you make sure you are not to blame when someone doesn't get what they want. :) In all seriousness, a voting process is the answer. Let people vote for the language features they want. Try to prevent them from gaming the system, but let them participate. On each iteration, assign a complexity score (let the community participate in setting this as well) and figure it against the popularity of the feature. Have a phase where 'no goes' can be evaluated (breaks other features). If it can't be put in because the design/prototype break other parts of the language, then put it in a status where it can be later reconsidered. This gives the community a chance to fix the problem. I think I could go on and on with this. However, the point is to let the community participate in the decision via a democratic process. Obviously, Sun wants to have some say in the features that they want to spend their resources on. Certainly they are entitled to work on features that they consider important. It's their money. However, if they will commit some resources to help with this work and manage these features to a project plan, then they can get open source volunteers to be more involved. As the features reach completion, they can get rolled into the next jdk. If they are not ready when the jcp decision is ratified, then it gets considered for the next version. The bottom line is, if the community wants feature X, then they need to do the work. However, the corollary promise is that if they do the work, then they will get the feature. SUN CENTERED GALAXY Joe and Alex seemed to very definitively take the position that we are talking about the community trying to dictate the allocation of Sun resources. They have a point. Sun is a company that can make it's own decisions about what makes sense for it's resources. However, those that are governing the process for introducing or managing Java language changes need to have a larger perspective. There are people that would be willing to work on these complex problems. However, it feels, right now that the investment could be in vain. The effort of managing language changes should not be about Sun and it's resources. It should be about managing the list of proposals, evaluating the prototypes, managing open source projects to do the implementations, and yes...evaluating where to deploy Sun's resources among the proposals. Sure, Sun can choose to work on something that is not in the top tier of proposals. That is fine. However, the mechanism for managing what gets in and what does not get in should not be built around where Sun is willing to spend it's resources. Simply, it is a difference in perspective that allows the community to participate more. BLOWING CHUNKS Language changes are hard. The ramifications are large. The detail in the proposals in non trivial. The prototypes take time. As with other business issues that require too many resources, this is a place for technology to be applied. An app that facilitates breaking the changes into smaller chunks, that can be worked on collaboratively, is required. It should allow the proposal to be shared. Maybe a wiki makes the most sense for the proposal. Maybe something more like Wave. There needs to be a project management component that allows the project to be broken into code modules. It should allow people to take on these individual code modules or tasks. It should allow these modules to be committed and run through CI. Fundamentally, it should use the best practices that we have established for how to run open source software products. If they can find a way to simplify the development for the open jdk. If they can find a way to break up the tasks into weekend sized pieces, then I think that they will find the uptake on the work will significantly increase. Afterall, with all of it's complexity, the jvm is not as complex as linux (as a whole). It's just that linux has done a better job of separating the development effort into subsystems and tasks that can be developed independently. WRAP UP Maybe I missed it, but it seems to me that they(the posse and the coins) just did not understand why the community is not participating the way they had hoped. I don't know that these are not all of the answers. However, I think that these relatively simple steps would go a long way toward engaging the community in a more productive way. I'm curious to know your thoughts. Am I way off base? I cross posted this on my blog (I wish there was a good way to integrate it with google groups). http://www.mindmeld.ws/blog/2009/09/23/project-coin-blowing-chunks/ LES --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
