Lists Home |
Date Index |
Bullard, Claude L (Len) <firstname.lastname@example.org> writes:
> It depends on the local issues. A single spec for a
> new technology might indicate a proprietary development
> ripe for IP exploitation. If it works, why not?
Seems to me you're trying to have your cake and eat it to: on the one
hand any spec. that is "ripe for IP exploitation" is ok, but OTOH, any
spec. that prematurely codifies practice is bad. How are you supposed
to know the difference?
> everything is in the commons and that assumption of
> community property for all things web is one way to
> sort out the naive and inexperienced including those
> who offer up single spec/single use specifications
> labeled or processed as standards. Respect for IP
> is the way forward. IP keiretsu in the form of consortia
> managed royalty free contributions will work both
> for ensuring that submissions are vetted under
> participation agreements, and for keeping as much
> IP as is workable in the commons of jointly indemified
Sure, but that seems only peripheral to the issue is when to spec. and
how much? A lot of the spec. world isn't about IP, it's about trying to
standardize business practices. Trying to use specs. to leverage first
mover advantages is a tad like bit like, <bad-metaphor> trying to keep
the wilderness pristine by building a theme park in it</bad-metaphor>
(though when someone does manage to sneak -- Netscape like -- under the
radar, the advantage can be enormous for a while).
> People make assumptions. That is how they learn. If
> they don't, they fail. Life and death in the ecosystem.
> We got here because too many stopped focusing on developing
> software and started playing the standards game. I blame
> the W3C squarely for that. This community made its own
> problems and this community will have to face up to the
> job of fixing the mythInformation it created.
Given the ambitions of "web services", the ill defined scope, the
previous history of universal interoperability specs of the same nature
(CORBA or the OSI stack anyone?) and the ever increasing pressure to get
to market I can't imagine why anyone would expect any of this to emerge
cleanly or rationally?
Every time I preach "how to do a system architecture" it usually
includes a phrase something to the effect of "use standards where there
is a significant body of best practices that clearly match the business
problems you are dealing with". IOW, pick you risks wisely...
> From: Hunsberger, Peter [mailto:Peter.Hunsberger@STJUDE.ORG]
> Bullard, Claude L (Len) <email@example.com> writes:
> > +1
> > except competing specifications are fine. for new
> > technology. competing standards are bad. they codify
> > practice as you say.
> If true, then a single spec. would be even worse; people
> would be even more likely to assume it is the only way to do things...