 |
Proposed Restrictions On Spec leads
One of the concerns regarding the JCP is the power and sometimes misbehavior of the powerful JCPSpecLeads. The problem is that presently a spec
lead can act as a dictator and the experts are essentially nothing more than advisors. This page proposes ways to make the spec lead a more constructive and cooperative body.
Candidate Selection
- Spec leads should be chosen from the best experts in the field, regardless of vendor representation.
Role of the Spec Lead
- Spec leads work to facillitate, organize the specification process.
- Sepc leads cannot operate as dictators
- Drive the discussion forward
- Spec Leads can vote as participants but do not receive additional decision making power
- Propose meetings, set discussion times
- Mediate disputes between members
- Spec leads cannot require participants to sign more than the ProposedLegalAgreements?. Non-Disclosure agreements are specifically not permitted, but not exclusively forbidden.
- Bring violations of the ProposedRulesOfDecsionMaking? up to the ProposedSupervisoryBoard?
Definitions:
- Vendor Affiliation - the employer of the spec lead.
- Vendor - that which sells, plans to sell or is likely to sell a technology based on/supporting the specification.
Issues:
- ProposedFundingForSpecLeads?
- MinimizingInfluencesOnSpecLeadsDueToFunding?
Discussion:
Leadership should be based on merit. What's wrong with vendor participation? What behavior are you trying to prevent and how does being an open source hacker or academic prevent this? --RobEvans
No need to lock out vendors. Just make sure that all the participants have the chance to contribute without being overruled/ignored. Use the voting rules used over at Apache, a single -1 vote on an issue kills it. --Geoff Longman
The problem isn't with having Venfors participate, it's in having them lead... I think we need benevolent dictators of each spec committee who have no vested interest in the spec... i.e. not from a vendor in the space. They need to be there to make the best decisions for the spec and for the Java community without being pressured and bullied by vendors. -Jason Carreira
I agree with Jason, I think the spec lead should be somewhat of a dictator because in a committee someone has got to make decisions and move things forward. I like democracy but I see it as counter productive because everyone has their own agenda and is trying to figure out how they can make things work out for their own benefit. Very few participate to give something back to the Java community. You need a neutral decision maker that can filter input from vendors and make decisions for the good of the community. I do think some checks and balances could be helpful (i.e. unanimous or 2/3 votes can override the leader) in making sure that the leader did listen to the experts/vendors.
We should be asking the question is the JCP even relevant. The JSRs that will be incorporated into the standard Java distributions, I could care less if Sun developed these behind closed doors. The only thing that will determine if they will be used is the java community. The other JSRs I think will fade away into irrelevancy or fill a very specialized niche. I personally haven't used one thing that has come out of the JCP (besides the stuff in the standard distributions) -Ryan Ackley
The Rules for Revolutionaries document, written by James Duncan Davidson, gives an alternative to a dictatorship, specially in a world where vetoes (-1) must be justified on technical grounds or are non binding.
The idea is: if a project gets completely stalled and paralyzed, due to disagreement, both parties start writing competing approaches in parallel, and are bound to offer their initiative "in code". This can result on alternative standards (e.g. SAX vs DOM), evolution vs revolution (tomcat3 vs tomcat4) with or without ulterior merging of alternatives into a "winner".
I think a SpecLead? is needed, but I don't see the need of more power than, say, a PMC Chair in Apache.
-SantiagoGala
May I point out that presently Spec Leads in the JCP can and often DO act as dictators. As a side effect of the enormous power, some specs have multiple spec leads (which I propose should be prohibited). The Spec Lead should be a fascillitator rather than a dictator. In order for legitimacy, the Spec must be accepted. Presently the blessing of JSR is enough. This will decline in the near future (as happened with other arbitrary spec boards) and we'll be left with the Market as the decision maker. I don't think this is bad, but in order for the process to not be a waste of time, they need to be acceptable on their merits. Dictators make decisions based on their own experience. This is not to say that communities always make the best decisions but the combined experience and counterbalence of interests is preferrable to an unbalanced process.
Santiago and I have the common experience of working in Apache and have seen that communities can operate together and create projects. I invite each of you to see how this process works before forming a decision (I'll post some links later)... Lets work towards a good compromise. I won't really accept a dictatorial spec lead. I'm not inherently opposed to vendor spec leads. This of course has nothing to do with participation of vendors, but as spec leads. Thus lets come up with a compromise. I propose:
"
Spec leads should be chosen from the best experts in the field, regardless of vendor representation. Spec leads work to facillitate, organize the specification process. Spec leads cannot operate as dictators. The community must come to a consensus or where appropriate, majority decision on the issues. The spec lead may vote as a participant, but has no additional vote. (We'll outline the decision making process later)
"
-Andy
Ok, dictatorship can be bad but so is ruling by committee. A few years ago when printers were a little more expensive. There was network printer committee formed to work out the specs for the printer in our wing of the building. The sticking point was what size paper should be in the different trays. Everyone had different needs. It took three months to work this out. It was an ugly battle for something so ridiculously simple. I think the spec lead should have the ability to make a judgement call when no middle ground can be found. -Ryan
I don't mean to be obtuse or unclear..but what is a vendorr in relationship to the Sepc Lead question. I am only asking because certain companies switch from the vendor to non vendor defintion in situations and we probably need a more clear definiton.
-Fred Grott, ShareMe? Technologies
Ryan, Look at our work on Apache. You and I generally come to agreement on POI. We in truth have no formal lead but I kind of have the unofficial role just because of my historic merit and my supervisory role as an ASF member (make sure you don't steal copywrighted stuff, etc etc). Oddly I encourage folks who disagree to stick up for themselves and Glen has proven me wrong on a few occasions and overriden me. Yet somehow we've only had one blowout ever...and it was minor. More minor that some of the stuff that I've heard goes on in the JCP. Now if shit hit the fan, like on Avalon, we can talk to the PMC or the ASF Board. (PMC is more a watchdog than a gaurd dog, the board has the teeth).. Oddly, we have never really had such a need. The short and skinny is that these conflicts are rare, far between and a good process makes them more minor. The distribution of power makes it impossible for one person to work their own interests against the interests of the project. Presently the JCP generally does not guard against this.
-Andy
Fred: I assume -- A spec lead employed by a vendor whom sells technology based on the technology being developed. For instance, IBM sells WebSphere? portal and one of the spec leads of JSR-168 (portal spec) is an employee/rep of IBM.
-Andy
|