Last week I blogged on Concentration at the ODF TC. My concerns were
First, at all meetings, office suite developers had a majority of votes.
Second, at all meetings, commercial voters had a majority of votes.
Third, for 4 of the 12 meetings, voters associated with a single code base (the OpenOffice family, including Lotus Symphony, of Sun/IBM and sometimes Novell) had 50% or more of the vote.
So, another week, another OASIS ODF TC meeting. What are the numbers this week? [Updated: the original minutes seem to have miscounted numbers: with Microsoft having 2 voting members at this meeting.]
Here is the rollcall [with the number corrected: it doesn't change much]:
+Peter Junge, Beijing Redflag Chinese 2000 Software Co., Ltd.
+Don Harbison, IBM
+Mingfei Jia, IBM
+Yue Ma, IBM
+Rob Weir, IBM
+Dennis E. Hamilton
+David Faure, KDE e.V.
Doug Mahugh, Microsoft
+Eric Patterson, Microsoft
Florian Reuter, Novell
+Michael Brauer, Sun Microsystems (presiding)
+Eike Rathke, Sun Microsystems
+Oliver Wittmann, Sun Microsystems
Voting Members are indicated with a + before their name.
12/1711/16 voting members present, so quorum requirements have been met.
So lets see how the numbers pan out, for sectional affiliation:
- IBM: 4/11= 36%
- Sun: 3/11 = 27%
- Novell: 0
- Microsoft: 1/11 = 9%
- KDE: 1/11 = 9%
- China: 1/11 = 9%
- FOSS: 0
- Institution: 0
- Individual: 1/11 = 9%
So this week, how have my three issues related to the concentration of power (the potential to pass or to block issues) fared?
1) Office suite developers: 91%
2) Commercial voters: 91%
3) Voters associated with a single code base: 63%
Even worse than before!
So basically only the presence of Dennis Hamilton stopped it from being a vendors-love-in.
And what do they vote for? A proposal from an IBM employee to classify defects into classes, which sounds OK until the fine print where the purpose is less understanding defects rather than prioritizing them: It is probably worth getting to a common understanding of defects and how much we're going to commit to resolving for ODF 1.2.
But who judges defects? The proposal reveals, I think, the mindset well:
We are fortunate to have so many ODF implementors on the TC to help us accurately evaluate defects and set appropriate severity levels.
It is not all bad though. A phrase mentions next-scheduled errata document. If this ends up meaning that the ODF TC may be moving the errata process to a regularly scheduled basis rather than treating them as unexpected exceptions or distractions from the main task, that would be a positive.