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.
> 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.
> 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.
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.
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".
People would quickly ask "what is the long-term plan here?" and you can't lie to them.