Followup: modularity, WebExtensions, and going faster

[Benjamin Smedberg]

Thank you all for the beginnings of a great discussion!

I'd like to follow up on a few points which I think were misunderstood.


   - The focus of my post is about requiring good module boundaries for
   code that wants to move quickly, and the notion that WebExtensions are the
   right way to do that. Although I like indulging in talk about making the
   entire browser modular, that is clearly not something we can accomplish
   soon. I am talking about the pipeline of development that we're building
   which starts out with test pilot, through SHIELD studies, to system addons.
   We are shipping these *today*, and shipping is a tedious and fairly
   high-risk process because we don't have modular isolation or testing.
   - I also don't think we should limit ourself to WebExtensions as they
   are today. WebExtensions are purely asynchronous today because of design
   decisions that Chrome made and we also accept that addons shouldn't be
   allowed to block the browser UI. That doesn't mean that we can't make API
   surfaces which are synchronous/blocking, if we feel that's the right
   tradeoff.
   - We can make choices about the "stability" of API surface: both APIs
   we're building internally, and even APIs we expose to addons. I'm going to
   follow up separately about what I think we should have learned from XPCOM,
   but if there's anything we should learn it's that frozen API surfaces are
   often the wrong choice.

We have a stated desire to let certain teams move much more quickly. This
includes Hello in the past, it includes a bunch of test pilot and shield
studies now, and it will include activity stream work in the future. What I
was trying to point out, with a long history of academic research, is that
there is a "physics" of software engineering that we cannot avoid: projects
and teams move faster when there are fewer modular entanglements, smaller
modules in general. We can train new employees and attract new contributors
better with smaller boundaries around the code that they have to understand
to be productive, and better documentation about where the boundaries are.

Richard is right that if we try to "remodularize" around our existing
infrastructure, some things are going to be really hard. It's basically
impossible to provide atomic sync with things designed the way they are.
But let's say that atomic sync is something that we believe is important: I
believe we *have to* spend the time to reorganize the system so that sync
as a module that stores passwords, bookmarks, etc is lower/more basic in
our module structure, and then we build our bookmarks UI, location bar,
etc, on top of that core structure. We are in charge of designing these
things.

We always *have* a structure. I believe that currently we have a structure
where Firefox is a large monolith which is very difficult to change
effectively. To change that, we don't need to and shouldn't rewrite it all.
But we should start carving off pieces so that they are smaller and have
real boundaries. I believe we should start with the things which are trying
to move faster right now. Maybe we should also start at the other end with
core infrastructure like sync. If we carefully carve off pieces, keeping a
longer-term vision in mind, we will end up in a place where there either is
no monolithic center, or we carved it down enough that we can
document/understand/hack on it more easily.

--BDS



On Thu, Oct 6, 2016 at 11:08 AM, Benjamin Smedberg <benjamin at smedbergs.us>
wrote:

> I spent a week writing a thing about modularity, webextensions, and going
> faster. I think it's important for us to decide the module structure of our
> code especially as we start shipping independent modules/going faster. And
> I believe that having better module structure, boundaries, and
> documentation is critical to our teams being more agile and also attracting
> contributors to the project.
>
> http://benjamin.smedbergs.us/blog/2016-09-03/modularity-and-webextensions/
>
> I personally think that we should double down on WebExtensions as a model
> and start using that for large parts of Firefox. But Andy McKay and Rob
> Helper had some good counter-thoughts and I've asked them to post here to
> elaborate.
>
> In the post I asked everyone to send followups to firefox-dev, so I wanted
> to start a thread here to collect responses. Over the next months I'd like
> this to turn into a firm decision about how we're going to build system
> addons; but I'd like to start by seeing what feedback people have and even
> whether I've framed the problem correctly.
>
> --BDS
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20161010/decb0fc6/attachment.html>