Re: [Wpack] Problem statement and scope for BoF

["Martin Thomson" <[e-mail]>]

On Thu, Aug 8, 2019, at 04:21, Jeffrey Yasskin wrote:
> That's a great point, and I'm adding a section 
> [...] for it to my document. However, I don't have very good content for that section. We had the ESCAPE workshop partly to try to find ways that Web Packaging might increase the risk of consolidation, and Martin is writing the report from there, but I didn't come away with any mechanisms that seem likely to have a big effect.

I agree that there wasn't much at the workshop that suggested how this could avoid some of the consolidation effects.
> 
> Martin, do you have a good list of ways folks are worried that 
> Packaging will centralize service providers?

Mozilla's position paper has my best thinking on that subject, but a few points for the purposes of summary...

The consolidation effects might be felt in several ways: in terms of driving traffic to sites that have the resources to preload links, in terms of inventivizing provision of content for majority clients, and as a secondary effect of raising the cost of business for publishers.

The latter point is not one standards organizations are well-equipped to handle.  It's a natural byproduct of having more standards.  There are two ways of dealing with that: 

1. Stop adding to the pile.  I know it's hard to tell engineers not to engineer, so I don't expect this to happen.  New stuff is just too appealing.

2. Having more and more accessible software for handling any complexity.  For instance, HTTPS didn't really take off until we had really good support infrastructure.  Jeffrey has done some of that with the tools around building packages, but that's a very small part of the picture.  We need more and better tools, including cognitive tools for understanding the effect of this sort of change.  The availability of those tools will always lag standardization.  I might speculate and say that the extent to which consolidation is driven by this sort of effort will depend on how big that lag is.