Perceived Barriers

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? public-vision-newstd@w3.org

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

Other notes

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