On Sun, May 16, 2010 at 09:10, Carsten Munk <[email protected]> wrote:
> So, this is primarily an e-mail to ask some questions to the two
> members of the TSG, that I think would not be sufficiently covered in
> a TSG meeting and answers might be better suited for the e-mail form.

Thanks for asking these questions openly Carsten.

> We're not working in the open like we're supposed to - even though as
> has been said - Intel, Nokia and we all know how to do it! But when
> there's a big reveal mentality active, the mode of the people
> participating switches to internal/private development, even if you
> are only tangentially related to the object/UX being revealed.

The questions you ask of the TSG are even more pressing, as it's been
said, at conferences, that MeeGo is ready to contribute to now. Sure,
people can raise some bugs around the barebones day 1 system; but even
low-level hacking will be inhibited by, say, filesystem discussions or
kernel settings which are being discussed in physical architecture
meetings at Intel or Nokia offices.

To be honest, for the sake of MeeGo, I *hope* some of these
conversations are happening behind closed doors - but, given some of
the public reaction to the btrfs thread, I'm worried they might not
be.

> In the future, in case you get another need to do a big reveal, how
> will you ensure that active, public development/work/process will not
> regress to not working in the open? Should the work for big reveals be
> done initially outside the MeeGo project framework?

It seems like the people working on big reveals for proprietary
devices or launches should be very separate teams who are "clients" of
MeeGo as much as any open source enthusiast. The MeeGo project - with
developers at Intel, Novell, Nokia, the open source community, and
others should be trying to deliver a product which meets the needs of
Intel & Nokia product teams.

The biggest problem is then finding a way by which the (say) Nokia
product teams can communicate future requirements without divulging
future plans. Perhaps this is the role two (of perhaps three future)
TSG memebers can play: representing, subtly, the overarching
directions their companies need MeeGo to go in. I suggest a third TSG
member so that the MeeGo project can maintain the separation between
it, and Nokia/Intel products.

Cheers,

Andrew

-- 
Andrew Flegg -- mailto:[email protected]  |  http://www.bleb.org/
Maemo Community Council chair
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev

Reply via email to