<div dir="ltr"><div><div><div><div>Thank you all for the beginnings of a great discussion!<br><br></div>I'd like to follow up on a few points which I think were misunderstood.<br><br></div><ul><li>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.<br></li><li>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.</li><li>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.<br></li></ul></div>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.<br><br></div><div>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.<br><br></div><div>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.<br><br></div><div>--BDS<br></div><div><br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 6, 2016 at 11:08 AM, Benjamin Smedberg <span dir="ltr"><<a href="mailto:benjamin@smedbergs.us" target="_blank">benjamin@smedbergs.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>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.<br><br><a href="http://benjamin.smedbergs.us/blog/2016-09-03/modularity-and-webextensions/" target="_blank">http://benjamin.smedbergs.us/<wbr>blog/2016-09-03/modularity-<wbr>and-webextensions/</a><br></div><div><br>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. <br><br></div>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.<br><br></div>--BDS<br></div></div>
</blockquote></div><br></div>