3 ms·

Uncertainty is bad, but it's unavoidable in this case, for two reasons: * They need feedback from addon makers in order to design the new API. * Mozilla does

Uncertainty is bad, but it's unavoidable in this case, for two reasons: * They need feedback from addon makers in order to design the new API. * Mozilla does all its work in the open anyhow. There is no way to avoid an announcement about an intention to change the API, before stating the API in full. Yes, it caused uncertainty, and that's a downside, but open development is generally worth it.

vanderZwan 11y ago
With that in mind it's both expected and perfectly fine if addon developers are up in arms about this change, as long as it doesn't stop Mozilla from designing a new API in the open while listening to the developers. Hostile feedback is still feedback.
mook 11y ago
> There is no way to avoid an announcement about an intention to change the API, before stating the API in full. Yes, it caused uncertainty, and that's a downside, but open development is generally worth it. It's quite possible to announce that they're starting to implement the new API, wait a year or two until it's capable enough, _then_ start talking about deprecating the existing one. Just like it was possible to finish implementing extension signing (or at least to the extent that people can automate signing) before deciding on a time frame to enforce it, or to get the automatic SSL certificate issuer (Let's Encrypt) working before talking about deprecating non-SSL HTTP traffic. Basically, don't put the cart before the horse, let people implement transition plans. Wanting to have better things is fine; scaring people without having actionable mitigation strategies isn't so nice.
- brighteyes 11y ago
  I agree a more organized PR approach might be more effective, but it would be impossible to keep a secret like that when you're doing open development. People would quickly ask "what is the long-term plan here?" and you can't lie to them.
  - mook 11y ago
    > People would quickly ask "what is the long-term plan here?" and you can't lie to them. Sure; but you wouldn't need to. Just don't have a time line set (as opposed to the 12 ~ 18 months set here). They've done it once with Jetpack already, that just didn't go anywhere because the APIs weren't flexible enough to actually not need all the underlying guts. Hopefully this one would have better results, but that requires lots of work on the part of Mozilla to actually implement enough API surface for the thing to be useful.
    - brighteyes 11y ago
      So you're suggesting they say "we intend to deprecate this feature", but not give a timeline? It seems much more open and fair to give a timeline. That way it's predictable and lets people plan.
      - mook 11y ago
        > So you're suggesting they say "we intend to deprecate this feature", but not give a timeline? Yes; but that only works if they don't actually _have_ a timeline. Do the necessary work to let people explore options, then evaluate and give a timeline (in the same order as what it took to get all that implemented). The timeline currently is "you have 12 to 18 months, but can't actually start". That's pretty much a recipe for frustration.
        brighteyes 11y ago
        I guess it's a matter of opinion, but I greatly prefer it they way they did it. Announcing "this is going away" without a timeline would make me worry "when? now? in a month?" Instead, by saying "12 to 18 months", I know this is a long-term thing and I can plan for it. The timeline is very useful information.
        feanaro 11y ago
        But the point is that they shouldn't have set the timeline until a replacement was reasonably in place. They could (and should) have said "this is going away 12 to 18 months after we've been able to determine what APIs are needed and implemented them".

vanderZwan 11y ago

With that in mind it's both expected and perfectly fine if addon developers are up in arms about this change, as long as it doesn't stop Mozilla from designing a new API in the open while listening to the developers. Hostile feedback is still feedback.

mook 11y ago

> There is no way to avoid an announcement about an intention to change the API, before stating the API in full. Yes, it caused uncertainty, and that's a downside, but open development is generally worth it. It's quite possible to announce that they're starting to implement the new API, wait a year or two until it's capable enough, _then_ start talking about deprecating the existing one. Just like it was possible to finish implementing extension signing (or at least to the extent that people can automate signing) before deciding on a time frame to enforce it, or to get the automatic SSL certificate issuer (Let's Encrypt) working before talking about deprecating non-SSL HTTP traffic. Basically, don't put the cart before the horse, let people implement transition plans. Wanting to have better things is fine; scaring people without having actionable mitigation strategies isn't so nice.

brighteyes 11y ago
I agree a more organized PR approach might be more effective, but it would be impossible to keep a secret like that when you're doing open development. People would quickly ask "what is the long-term plan here?" and you can't lie to them.
- mook 11y ago
  > People would quickly ask "what is the long-term plan here?" and you can't lie to them. Sure; but you wouldn't need to. Just don't have a time line set (as opposed to the 12 ~ 18 months set here). They've done it once with Jetpack already, that just didn't go anywhere because the APIs weren't flexible enough to actually not need all the underlying guts. Hopefully this one would have better results, but that requires lots of work on the part of Mozilla to actually implement enough API surface for the thing to be useful.
  - brighteyes 11y ago
    So you're suggesting they say "we intend to deprecate this feature", but not give a timeline? It seems much more open and fair to give a timeline. That way it's predictable and lets people plan.
    - mook 11y ago
      > So you're suggesting they say "we intend to deprecate this feature", but not give a timeline? Yes; but that only works if they don't actually _have_ a timeline. Do the necessary work to let people explore options, then evaluate and give a timeline (in the same order as what it took to get all that implemented). The timeline currently is "you have 12 to 18 months, but can't actually start". That's pretty much a recipe for frustration.
      - brighteyes 11y ago
        I guess it's a matter of opinion, but I greatly prefer it they way they did it. Announcing "this is going away" without a timeline would make me worry "when? now? in a month?" Instead, by saying "12 to 18 months", I know this is a long-term thing and I can plan for it. The timeline is very useful information.
        feanaro 11y ago
        But the point is that they shouldn't have set the timeline until a replacement was reasonably in place. They could (and should) have said "this is going away 12 to 18 months after we've been able to determine what APIs are needed and implemented them".