On 2014-06-04, 5:01 PM, Chris Karlof wrote:
I propose we develop an add-on to make custom Sync configs easier.
Having written a "tech brain dump" reply, I'd like to step back and try
to evaluate what we want to accomplish *before* we commit to an
implementation strategy. Full disclosure: I prototyped a technology
implementation before evaluating just a few short days ago.
From where I stand, what we must do is pin down what level of
organizational support we are going to give to custom auth and custom
service endpoints. The costs of building UX -- in tree or add-on -- are
small compared to the ongoing maintenance, documentation, and testing
costs that comes from supporting this feature. If we're not going to
commit to the "custom endpoint" feature for at least, say, two years
[1], then we shouldn't spend a minute building an add-on or any support
for an add-on.
In my opinion, we should absolutely commit to this feature. Principle 5
of the manifesto states [2],
"Individuals must have the ability to shape the Internet and their own
experiences on the Internet."
We are fighting a wave of centralization. We've been pushed to
centralize our own service offerings, and we've discovered first hand
how difficult it is to develop a de-centralized ecosystem.
We have a relatively low-cost opportunity [3] to do something aligned
with our mission; to do something that is squarely aimed at our valuable
tech wizards user type, many of whom are feeling abandoned by Mozilla's
pro-mass market decisions. Let's ride the wave of anti-surveillance
sentiment and maintain our talking point, that "you don't need to trust
Mozilla to use Firefox Accounts".
Before we build an add-on, or an add-on API, or a native widget
solution, we need to decide if we're going to make this a first-class
feature of our product offering. And if we're going to support it.
I know where I stand.
Nick
[1] I have no idea what the right time frame is. Basically, are we
going to support this through at least an entire ESR refresh? We're
going to miss the ESR 31 release, and ESR is every 7 releases (I think),
which makes the next one ESR 38, followed by ESR 45. That's 14 trains;
14 * 6 = 84 weeks, which is getting up to two years.
[2] http://www.mozilla.org/en-US/about/manifesto/
[3] I believe that the up-front costs of getting UX and automated
testing in place will be relatively small; on Desktop, these endpoints
need to be configurable for testing anyway. On Android, getting native
UX or an add-on API in place is more work, but still pretty small.
_______________________________________________
Dev-fxacct mailing list
[email protected]
https://mail.mozilla.org/listinfo/dev-fxacct
