Perceived or real barriers to participation in W3C, gathered from various discussions and comments as part of task force about Making W3C the place for new standards. Comments or suggestions? email@example.com
Participation / Membership / Culture
- organizational commitments (rather than individual commitments)
- Related: requirement that AC Rep join a group
- cost of Membership
- face-to-face meetings cost too much or aren't worth it
- not enough time to do the necessary work
- the community does not include people I know.
- Related: My customers want this work to go on somewhere else.
- Related: People make decisions about which venue to choose based on whom they know.
- don't have interest or energy or see need to move document through various standardization phases (e.g., implementation, wide review)
- difficult to get grassroots efforts supported in an environment of large IT companies and W3C staff.
- w3c does not effectively manage some of the problems that arise in work going on in very public fora, including poisonous participants / civility too often sacrificed. Some specific types of disruptive behavior including trolls, amateurs with too much time (denial of service), domain experts who expect to be trusted without question, behavior representing non-invented here attitude (associated at times with generational divide). For help, see video on open source projects and poisonous people.
Process / Legal
- parts of process inherently too slow (e.g., 4 weeks for charter review)
- expectation of consensus-building with broader community
- wide review requirement of process burdensome
- implementation experience requirement of process burdensome
- don't know the W3C process; seems complicated or time-consuming to learn; not transparent enough to me how things work.
- don't want to lose control of my work; want maxium flexibility.
- copyright license not open enough
- concerns about the W3C Royalty-Free Patent Policy
- concerns that the W3C Royalty-Free Patent Policy does not provide adequate protection during implementation phases.
- concerns about role of W3C Director in process (of assessing consensus)
Operations / Infrastructure
- publications requirements burdensome
- tooling or infrastructure not what I want (e.g., use of mailing lists)
- want a document that continues to evolve
- want modern tools, not just mailing lists
Technical / Architecture
- differing view on what is important for the Web
- differing view on Web Architecture
- concern that particular technologies will be imposed (e.g., URIs, XML namespaces, RDF, ...)
- competing technology suggests ideas will not be welcome
- work doesn't seem in scope for W3C
Output / Specifications
- Specifications to hard to read, too complex, too long
- Hard to figure out how to implement
- Need more examples, need more context (how technology X fits in)
- Need more reference implementations or at least tests
- Want to be able to annotate specifications with developer comments
- Styles look old-fashioned
What changed since W3C was created that motivates change in process?
- Easier and faster to deploy technology
- Greater number of stakeholders
- Expectations about formality of standards processes have changed