As a Mozilla engineer who worked on / reviewed some of the pocket and
reader mode stuff:
On 18/06/2015 07:44, Dan Stillman wrote:
- Is the plan actually to open this feature up with a documented API and
in a way that doesn't privilege a single proprietary service?
This is certainly what I've been hearing, yes. We're gathering telemetry
& other data to see how this integration works out before deciding how
to move forward, AIUI. Note that I'm an engineer, not a decision maker,
so...
- If so:
- When?
.... I have not heard a concrete timeline yet (could be I missed it -
there's a lot going on). Also not my decision. I trust the people making
it, though, and I wish you would too.
For evidence that we are serious with continuing to develop this stuff,
I guess I can point to https://kinto.readthedocs.org/ and
https://github.com/mozilla-services/cliquetis for now, in case that
helps you trust me...
- How can we reconcile that with the way this feature has been
developed so far (in secret, not on the normal release track, neither
with a public API nor positioned as one, and with trademarks in the pref
and the toolbar)?
All the bugs for the implementation that I've seen were open and never
moco-confidential or whatever, so I strongly disagree with "secret".
Release track: because we had a ship-by date for 38.0.5 and the pocket
integration was finalized after 38 left m-c, and so having it ride the
train was simply not possible. We are working to improve both process
and product (ie Firefox internals) so we don't have to do this again in
future. We will be talking about this in Whistler as well.
As people have said before now, we ship stuff with trademarks all the
time, including but not limited to the search engines, safebrowsing, the
facebook integration, etc. etc. etc. That by itself isn't really at
issue here.
Why are the prefs so specific: again, timeline. We did not have the time
to implement the first attempt here in a beautifully abstracted fashion
prepared for yet-unknown-specifications-for-other-services, so we
didn't. We implemented the initial desired functionality as quickly and
efficiently as possible.
(searchplugins as mentioned in a reply upthread is a false analogy
considering that had been implemented in suite for a long time and a
good part of the implementation was just copied/reused.)
- What can we do to help move the process along?
Right now, nothing specific that I'm aware of.
Constructive ideas regarding API requirements, UX flow (how does a user
pick a service) and what alternative services should be considered,
maybe, but I don't know if it isn't too early for some of those, either.
If you want to take a stab at that, it'd probably be good to start a new
thread, on firefox-dev ( https://wiki.mozilla.org/Firefox/firefox-dev );
this one has run its course.
If you have answers for these questions, please share them. If not, I'm
not sure why you're trying to derail the conversation before they're
answered.
At least half of what I've said above, and probably more, had already
been said. People are just reluctant to believe words without
implementation to show for it. As an engineer, I sympathise with that
feeling, but it does mean I don't really understand why people keep
asking the same questions.
Saying, "hey, these people are experts, are you an expert in this
particular field?" is NOT an insult.
We're
not discussing database design or tax law. The concepts here —
transparency, privacy, software freedom, interoperability, the
commercial/non-commercial balance
There are some items missing from this list, such as:
- market research/competitiveness
- marketing plans/campaigns
- usability
- user research
- implementation/engineering constraints
which are also all important when you're implementing a new feature in a
web browser. Sheeri's implication was that a lot of commenters seem to
not have considered any/some of these factors, or considered the fact
that the people who made decisions about them might be more experienced
than the commenters - maybe because they think they ought not to be as
important as any of the ones you listed.
(Aside/example: as an engineer reading this thread, it's been
excruciating to see the number of times people suggest that building
something like the pocket service is "easy". Codswallop.)
Mozilla is a weird org because it uses software to advance a mission. We
are not strictly a lobbying organization (though we do that), an
education org (though we do that), or a software vendor (though we do
make software).
From your list of concepts it sounds like you want the FSF or the EFF.
That's fine, they're great organisations and we partner with them on
some things. But please don't let's pretend Firefox is operating in a
vacuum, that we can *only* focus on the values you listed, and that the
aspects I listed don't matter at all.
You can't ship software without considering engineering constraints. You
can't ship usable software without some degree of UX/UI care and user
research. You can't compete in a market with multi-billion-budgeted
competitors without doing market research and staying focused on
building something that works in/with that market. You can't compete
against billion-dollar marketing campaigns by not doing any marketing
yourself.
All of those concerns helped guide this decision in addition to the ones
you listed, and if you do not take them into account it is going to be
hard to understand Mozilla's decision.
~ Gijs
_______________________________________________
governance mailing list
governance@lists.mozilla.org
https://lists.mozilla.org/listinfo/governance
