On scoping and modularity

Hi,

Back on January, we started a useful but somewhat difficult discussion
on our path to "WebRTC 1.0"; for various reasons, including our need to
move forward with constraints in getUserMedia, further discussion on the
topic has stalled.

There are several reasons that makes this discussion still (and probably
even more) important, so I would like to propose to re-open it, with a
proposed way forward, while also trying to appease some of the worries
that I heard during our previous attempt, based on my experience with
the development and adoption of Web APIs.

First, the reasons I think we need to have that discussion are:
* we started the standardization efforts on WebRTC 3 years ago; none of
our specs have reached last call, even though an already impressive and
growing number of products rely on our technologies. Unless we make an
explicit effort to finalize and freeze the technologies that are already
in wide use and deployment, we will keep adding bits of new features
here and there, leaving the market under bewilderment as to what may
change under their feet (a regular complaint I've gotten from product
managers at WebRTC conferences)

* it was brought to my attention that the dashboard that sets Internet
Explorer roadmap [1] indicates that WebRTC 1.0 is “not currently
planned”, while an ORTC-based version of the API (assuming it would form
the basis of a 2.0 version) is “under consideration”; while there can be
debates about the exact interpretation of that dashboard, when combined
with the abundant critical feedback we've gotten on the reliance of the
current API on SDP and offer/answer, I think there is a clear need for
the group to be able to move to the next iteration of some of the pieces
of the API; but we can't possibly do that until we finish the current
work, and we can't finish it if we don't set ourselves a limited scope.

1. http://status.modern.ie/webrtcwebrtcv10api

I guess the first thing we would need to get consensus on as a group is
that we need to determine the scope of our 1.0 efforts, and that we need
to determine it now.

Assuming there is such a consensus (which is not proven yet), then we
will need to get consensus on what this 1.0 scope is.

Determining this is probably more tricky; my personal view, informed by
the thread we had back in January on what developers out there need from
us, is that we should basically finalize what is already implemented or
being implemented today; at a first approximation, this would mean
mostly what is in the current WebRTC specification. In other words, my
suggestion would be that we explicitly agree not to add new features in
the existing specification.

Now, we have already identified features that we know we want sooner
rather than later, especially around optimizing the integration with the
protocols stack.

My proposal would still be that we don't include these additions to the
main specification (since they are by definition much less mature), and
instead develop them as separate modules.

I have mentioned using modularity to help us manage our focus and
schedule a few times, and heard generally the following arguments
against it:
* putting a feature in a module means it will be implemented later, or
not at all, and risks actually killing it

* creating a module is costly specification-wise and may create gaps

On the implementation aspect, my experience shows that, for better or
for worse, the document in which a given feature is specified as little
or no bearing on the implementors decision to adopt the said feature.
Implementors always end up deciding what they implement based on the
needs they see in their market, almost never based on what a
standardization group sets. So putting a feature in the "main" spec or
in a module has pretty much no effect on whether the feature will be
adopted or not, and each feature needs to demonstrate its usefulness and
appeal on its own, no matter where it spec'd.

On the editorial side, I'll easy admit that modularity doesn't come
cost-free; but in the priority of consistuencies [2], the cost to
specifiers come well below the cost to developers, and we've heard loud
and clear from developers that what they need the most at the moment is
stability and polishing of existing features. If that means we need to
put more efforts in achieving that goal, that's a reasonable cost to
endure, and I'll be happy myself to contribute to the efforts that
bringing more modularity requires.

I'm interested in feedback both on the need to scope our 1.0 work, and
on the proposed scope I'm suggesting in this message.

Dom

2.
http://www.w3.org/TR/html-design-principles/#priority-of-constituencies

Received on Wednesday, 23 April 2014 16:09:22 UTC