Views
Blueprint
Contents |
blueprint.formeego.org DRAFT
(aka MeeGo 2.0)
Background
It would be odd to argue that the MeeGo Project doesn't have problems. Nokia, one of the founding partners, has fundamentally changed its strategy; the Linux Foundation are an umbrella organisation who like to say "no"; the project management and leadership are conspicuous by their absence. All of this affects MeeGo's "customers". David Greaves' series of blog posts, Restructuring MeeGo, touches on some of the issues currently facing vendors who want to take MeeGo and ship it:
these organisations are not your typical linux hackers, nor are they linux-friendly IT teams. They are software product delivery professionals. They care about more than just the source that comes out of MeeGo - they care about managing their build and delivery environments. The last thing these people want is to re-invent the wheel; they are under pressure and need as much help as they can get - automation, QA, progress reporting, minimising overhead and cookie-cutter deployments.
As has been widely noted, we're currently in a "war of ecosystems", and it's a new ecosystem - with the opportunity to differentiate - that these vendors want. An ecosystem-in-a-box.
The problems facing MeeGo will instill fear, uncertainty and doubt in anyone looking to adopt it. What's the MeeGo roadmap? How do they shape the direction? Similarly, ecosystems live and die by the contributions of third party developers - both professional and hobbyist - but how do they get involved in the project? How do they distribute their software?
MeeGo has a governance structure which should address these problems. Unfortunately, it is failing to execute its own rules. The Technical Steering Group is delegating all decisions to the project owners - meaning that a TSG meeting hasn't been held in ages and is viewed as an "insurance policy" within the project. Everything is being decided by project owners, architects and maintainers - except for the things falling through the gaps (such as leadership on the apps.meego.com issue, architecture discussions which go unanswered, addressing the lack of pubic architecture and roadmap discussions, addressing the "fork" in QML components, and more).
Although Arjan van de Ven said, during the MeeGo 2011 Conference, that MeeGo needs to innovate faster, MeeGo 1.2 Harmattan has shown that a modern technology stack isn't necessary to build a compelling product. Therefore, this proposal addresses the innovation necessary in the MeeGo Project for it to really deliver on the execution of its promise as an open project.
This is not just an empty proposal for MeeGo to change. That is tilting at windmills. Instead this is a concrete project which can live alongside MeeGo Core to show how the rest of the project could work. It is a sibling to the MeeGo Project whilst delivering a MeeGo ecosystem.
Proposal
TBC:
- Open governance
- Open development
- Roadmap
- More modularisation of project
- MeeGo is "default" upstream
- Same cadence of releases as meego.com
- Migratable to Blueprint from MeeGo, and from Blueprint to MeeGo
- Ecosystem-in-a-box
...all aiming to provide vendors and developers a cleaner project in which to operate.
Governance
Project Steering Group
Responsible for overall delivery of project, and organisational activities:
- chairing the monthly online meetings of project & team leads. It will be hosted on IRC and open to the public.
- chairing a yearly get-together (at the MeeGo Conference?) of the project & team leads.
The PSG consists of:
- Three people, elected by the community (voters' eligibility identified by contributions to the other projects & teams). Each person serves for a year (meaning two releases). The Spring release triggers the start of the election period.
- Two seats allocated to Intel and the Linux Foundation. This is expected to be a transitionary arrangement and reviewed at each election. Hopefully, once the open governance and community has been established, members from these organisations - and other organisations taking part - will be elected on their own merits.
Projects
Each have an area of responsibility, with meego.com considered the default OBS. Each has an identified project leader and project architect.
- Core - responsible for building the smallest set of packages which will boot and provide a basis for a Qt-based user interface. Provides a slim Qt, Qt Mobility Core, essentially MeeGo API, runtime.
- Build - provide the packages necessary for Core to build itself, and other sensible distribution/application-building tools.
- UXes - provide a user interface environment, possibly applications and possibly UX toolkits (based on Qt Quick Components). There may well be commanlity/collaboration between the difference concepts. Device vendors may have internal UX projects to provide bespoke, differentiating, user interfaces on their devices. Treating our own UX layers in the same way a vendor would ensures that the appropriate processes and boundaries are in place to allow them to do that.
- HW adaptation - necessary work to get Blueprint running on a particular piece of hardware. There may well be commonality/collaboration between the different device targets (due to architecture etc.) Similarly, hardware vendors may have internal projects along similar lines to prepare MeeGo for their devices. These may or may not fall under the overall project at a later date. Treating our own adaptation layers in the same way a vendor would ensures that the appropriate processes and boundaries are in place to allow them to do that.
- MeeGo Compliance - compatibility project to get Blueprint to be MeeGo Compliant. This is necessary as Core is a restricted subset of MeeGo packages, and therefore additions needed for vendors to ship MeeGo Compliant product.
- Apps - apps.formeego.org, facilitates and encourages a third party software base. This is a key part of the ecosystem-in-a-box. Responsible for the Apps Client which may be shipped as part of a product/additionally installed, the web-based catalogue, Surrounds and the QA processes.
- Community Edition - builds on the other projects to ship an end-user installable showcase distribution for multiple devices.
Future projects may spin out of, for example, UX collaboration, such as a strong, compelling set of applications which can be used to build a usable distribution.
Teams
This teams are cross-cutting and provide services to the project. Each has at least one team lead.
- Design - provides UI and UX skills and assets like logos and icons.
- Comms - communications, press releases, website content.
- Infrastructure - IT provision such as OBS, mailing lists, storage, servers.
- Community - community management liaison, events
- Vendor Support - provides support (such as automation and advice) to vendors, and ensures the projects are best structured and placed to meet the needs of device manufacturers.
Tools
All builds and processes based around OBS, documented and available for integration with vendors' own systems. Websites and output hosted on formeego.org (subject to timoph's acceptance, he on first PSG and/or Infrastructure teams?).
Code of Conduct
TBC: open development/mutual respect/hippie talk/etc
Bootstrapping
TBC: How do we take this forward? It's not just a proposal, we want to actually do it!