Totally understand that it’s strange we didn’t talk about these openly in a note of this sort.
The other 2 are in their very early stages, just past Gate 0, and only a few weeks old.
One specific point:
Those who pitched these projects really don’t have many resources/people right now and have a lot of time pressure to show progress before a Gate 1 evaluation that will come within months.
In some ways, that’s ripe for participation/contribution, but there’s a tension on having time to set it up well. Our participation/ collaboration team hasn’t had the chance to reach out to them yet to help understand how contributors can help and how to design that. That’s an important to-do in the weeks ahead.
2 big questions for me (we don’t have answers!):
Would there be situations when we need to keep new ideas quiet/closed for competitive reasons? On what criteria should we evaluate this? Should we be conservative with this (e.g. default = closed) or be willing to take more risks with being open generally?
In an innovation process like this, typically the early stages are short and not that many projects progress. Also, things are shut down quickly (if you’re doing it right). This can be hard on the people involved (especially founders) – their egos almost by definition take a hit. What are the implications of this happening in public? For those people? For Mozilla’s reputation in the open source community? What about the implications on the volunteers who got involved, but then the project doesn’t get resources moving forward? How do we design this well?