Forgot another important aspect. See below. :) Gil Quim (Nokia-D/Helsinki) wrote: > Hi, > > ext Graham Cobb wrote: >> On Tuesday 27 April 2010 10:16:07 Quim Gil wrote: >>> The plan is to have in few weeks a first complete MeeGo release followed >>> by a roadmap to work on the next release. Once this is out the MeeGo >>> project shouldn't have any obstacle to have all the daily work and >>> routines in the open. >> I am very disappointed in this. I really expect a project which is >> sponsored >> by the Linux Foundation to have **all** discussion on public mailing lists. >> No exceptions. > > That is my expectation too. However, there is a difference before and > after a first release. I'm not defending the current situation of closed > development prior to the first MeeGo release, but this is the reality. > > Before the first MeeGo release there is a lot of code being developed > behind Intel or Nokia closed doors or in some public repo somewhere. > Those pieces of software are being developed more or less by the same > teams that were developing them before the MeeGo launch and without much > changes. The release dates are around the corner and those teams from > Intel or Nokia are not really in a condition to receive and process much > feedback at this point, noting that such feedback might include > prospective contacts from potential industry partners, media > sensationalism, users asking when that piece of software will be > available for their devices, etc. > > Then in few weeks a full MeeGo stack will be released, news and blog > posts with screenshots will fly, deep and superficial feedback of happy > and unhappy people will circulate, etc. All good! A roadmap for the next > release will be published and the project will be finally in a situation > to build a daily routine based on plain simple open development. > > >> Each MeeGo subsystem should have its own mailing list, >> visible for anyone who is interested. > > This is a comment aside but yes, we need to discuss how the daily > routine of project discussion is held. The current approach is to > concentrate on the current lists (-dev, -sdk and -l10n) and spin off new > ones only when the traffic deserves that. > > In the Linux Collaboration Summit a speaker of IBM explained that at > some point they forbid internal technical discussions about development > of open source components, forcing their own engineers to go and have > those discussion in the upstream projects channels. I find that is an > excellent idea: after the MeeGo release discussions about OSS > development through private emails should be a well justified exception > and not the norm. It really helps nobody: not to the development of > those OSS components and not even to the interests of Nokia/Intel. > > >> I have no problem with benevolent dictators -- I have a problem with calling >> MeeGo an "open project" if decisions being made behind closed doors, >> particularly technical decisions. If there is some concern over the amounts >> of traffic on public lists then you could require some sort of qualification >> or sponsorship for the privilege of sending to the lists: but the >> conversations must be visible for all! > > Improvising a bit here, the reasons for having private discussions prior > to the first MeeGo release are: > > - Building common proposals first. Nokia and Intel don't aim to have > everything polished before discussing every bit publicly, but having a > common plan in place and going through the first rounds of discussion > internally before makes some sense. > > - Having public roles first. The average Nokia or Intel employee working > on something specific wants to know what is his/her official MeeGo role > so they know when are they speaking for themselves, as upstream > maintainers, as company employees... Having a full release out makes > things easier for everybody. > > - Having clear instructions from managers first. The average Nokia or > Intel employee working on something specific probably has a manager > concerned on deliveries for release X. Depending on managers and teams, > open development is already assumed - or not. Everybody know we need to > change this culture but when it comes to pressure, having the first > release still clearly wins. > > - Anything with a UI is still very sensitive, specially in the Handset > UX. In theory you could indeed go to a public mailing list and just > start discussing. In practice, the moment you do this you need to be > prepared for a significant amount of feedback and noise coming from > users and media. We have seen examples of this every other week. A lot > of new development in MeeGo has to do with these areas (desktop & apps). > Nobody wants to be the guy quoted in the media before it's the right time. > > - Having consolidated/specialized channels? I'm wondering myself, but > there might be some personal resistance (combined with the two points > above) to go to meego-dev to share some development info and opinions if > there is a remarkable risk of starting a long thread with high noise to > signal ratio originated mostly by people not related to the development > in that area that will be of little help to deliver sometyhing better > sooner for this release in few weeks. It is much easier to have such > discussions in the "intimacy" of upstream projects, IRC, etc, directly > with most of the people that anyway will make a difference. I know, not > optimal and unfair in most cases. Worth discussing further, knowing the > opinion of the core developers.
- An additional point affecting specially Nokia developers is that some of the future MeeGo components that we are contributing are being relicensed as open source as we speak. Before that happens those developers are somehow tied as well. In the past weeks we have been opening several components that are now landing in public repositories and will get their own public development routines in place. You can still complain that we should have opened before and faster, but from my perspective (seeing how the process is working from the inside of the company) I'm actually quite happy that all this relicensing and publishing is happening! > >>> There might still be some areas under the shadow, but always related to >>> new developments e.g. imagine the arrival of a new cool UX category or >>> key platform feature. Once they are released they go to open business as >>> usual. >> That is not acceptable if you want the privilege of calling the project an >> open project. If you want to be able to keep some developments secret, that >> is fine but then it is not an open project, it is a closed project which >> chooses to release code with an open source licence. > > Please let's be reasonable considering our commercial context: > > - Even The Linux Foundation wants to have confidentiality before > releasing an announcement with the endorsement of dozens of companies. > > - You could start e.g. the In-Vehicle WG posting an email to meego-dev > asking for people interested, or you could go and contact the industry > players first and announce the new WG already with some cool names in it. > > - Intel, Nokia or any other company can contribute at any time a new > feature to an upstream project that has been cooked privately over the > past months. > > - Any MeeGo developer or team might well want to have some internal > drafting before coming up with a proposal. > > All these cases are usual in any work environment, including open source > projects. > > If you still have concerns let's talk about concrete cases. If there are > cases that are indeed unacceptable I want to be the first one working to > convert them in good examples of open development. > -- Quim Gil open source advocate MeeGo Devices @ Nokia _______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
