Hi, CCing TSG members just in case and sharing my personal take below. ext Carsten Munk 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. > > Now, there is currently in the MeeGo project what I've heard described > as a 'big reveal mentality' by someone - regarding Handset, Netbook > UX, etc. Now, I can understand why the project needs to do this - the > press would tear you apart if not done right, so the UX'es are not > what I'm here to discuss. > > What I'm here to discuss is what it does to the project. A big reveal > obviously requires a great deal of secrecy for the parties involved. > In this case, it's two or more big companies and well, maybe > unintended, most of the MeeGo project structure (release management, > OBS/repositories, bug tracking, testing, developer documentation, > etc.). The secrecy seeps through almost every single aspect of MeeGo > and it -is- hurting our idea of public R&D. I have plenty of examples, > but this is not important to the topic. > > 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. > > And I think that's the main source of all our so called 'openness' > problems - not malice, conspiracy, laziness or whatever. For the near > future until UX'es are out, the big reveal mentality will have to stay > - and I respect that. I want a blazing start on a good future in this > project with big fanfare. It's the future I'm worried about. > > Finally, my questions to the two members of the TSG are: > > Would you agree that the big reveal mentality has been hurting the > MeeGo project extensively in terms of having public R&D up to now? > > What will you actively do to prevent the same working patterns where > people have not worked in the open due to the big reveal mentality, to > continue after the UX reveals? > > 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? > > Thanks in advance for your answers.
Actually I don't think big reveals around platform development are useful for the MeeGo project. Once the project is deployed with all working groups and related UXs and a public roadmap process in place, MeeGo should be build on simple and plain open development. Indeed, we are not yet there. But in a few weeks we will have the sensitive UXs out, the MeeGo project structure will hopefully be populated with names in the couple of layers below the TSG, the plan for the Q4 release will be out and also the official processes will be public. In such context, the news around software development will be hopefully more based on features implemented and testable rather than about big reveals. The MeeGo big reveals should come mainly from business centric announcements: devices launches, companies announcing MeeGo involvements, and so on. On the software development side, if there is a big reveal from specific vendors / projects it will be around items developed for a while on a private or public side and then offered or contributed to the MeeGo project. Since the MeeGo roadmap and plan for the next release will be public, nothing disruptive AND secret should be in the pipeline distorting the development of the ongoing unstable release. The success of MeeGo is build on top of openness and predictability. Big reveals are not very useful for vendors having to plan their products well in advance. -- Quim Gil open source advocate MeeGo Devices @ Nokia _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
