Your conclusion that coin fostered a modicum of competition rang true for me. Given that the emphasis lied very much on: Only a few will make it, I really had to stop myself from pointing out the first flaws that came to mind for those proposals that I was ambivalent about (but not against), just because it felt like that might get in the way of the proposals I really wanted to see.
I've been banging on the drum of: You aren't properly fostering the community, which is why you aren't seeing the kind of participation you are hoping for, for a while now. FWIW, I'm actually in favour of requiring a prototype for a complete proposal, a Joe mentioned was at one point the plan for coin '09. Of course, there should be more phases, and whomever is the benevolent dictator (something that still isn't entirely clear to me - talk about miscommunication!!) needs to make earlier calls. Don't hide behind "It's complicated". We know that. If you change your mind on something you already soft-committed to earlier, we understand there were good reasons. But, if someone makes a proposal that you just know is unlikely to ever make it through, the earlier you say that, the less effort this person wastes. And, as I've said before, wasting your communities' time is a fine way of destroying it. (even if you don't think people flailing away at proposals that don't cut it and probably never will is a waste of time, they surely do, and that's what counts!) A corrolary to this is that you can reverse the process: If sun claims: We are not opposed and would in fact welcome feature XYZ, but we just don't have time to add it, then a community of fans can come together, build a prototype, a JLS patch, do some research, whatever you need. The community is much more willing to put in that kind of work if they already know that work will likely be going places. On Sep 24, 3:53 am, "[email protected]" <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
