From The Linux Foundation

Links to documents used in the meeting

Agenda

Overview of the Linux Standard Base

Linux Foundation Business Process

Minutes

Workgroup Leadership Meeting
February 14, 2007
New York City, New York

Attendees

Joe Alexander (Bull)
Peter Badovinatz (IBM)
Arthur Barstow (Nokia)
John Beauvais (IBM)
John Cherry (TLF)
Alan Clark (Novell)
Kathy Eriksen (TLF)
Erich Forler (Xandros)
Tim Golden (Bank of America)
Ibrahim Haddad (Motorola)
Tom Hanrahan (TLF)
Dirk Hohndel (Intel)
Stephen Harris (Xandros)
Gerrit Huizenga (IBM)
Greg Kelleher (IBM)
Dan Kohn (TLF)
Mika Kukkonen (Nokia)
Amanda McPherson (TLF)
Marc Miller (AMD)
Ian Murdock - via phone (TLF)
Ron Pettit (free agent)
David "Lefty" Schlesinger (Access)
Mats Wichman (Intel)
Jim Wasko (IBM)
Andrew Wilson (Intel)
Jim Zemlin (TLF)

Welcome and Intros

John Cherry brought the meeting to order, welcomed attendees, and everyone had a chance to introduce themselves and the roles they played in the working groups. Ian Murdock was snowed in, so we piped him in on speaker phone.

Jim Zemlin arrived earlier than he even expected, so Jim started the meeting by describing how the merger of OSDL and FSG was conceived and executed. The merger and mission were determined by the board of directors from both OSDL and FSG. The new mission combines the previous missions of OSDL and FSG. The new mission is to promote, protect and standardize Linux. The boards were not completely satisified with the effectiveness of the OSDL working groups. A new model was proposed which included advisory councils, workgroups, and the LSB. This new model focuses on collaboration as well as the standardization of Linux. The LSB is the anchor point for collaboration activities across the workgroups and will provide a framework for the position that LSB certified applications should run on LSB certified distributions.

Linux Standard Base

Via speaker phone (which became flakey at times), Ian let the group through the LSB overview. See "Overview of the Linux Standard Base" above. Ian re-enforced the notion that applications written to the LSB can run on any compliant distribution. The LSB does not define new standards, but tracks to best practices as they emerge. However, the LSB is taking a more "anticipatory" stand with capabilities that might become defacto standards by working with the community and upstream efforts. Anticipatory standards can be rolled out in the form of "optional" LSB modules until they are incorporated into the certifiable LSB. In thinking of Linux in terms of a platform, the LSB is the highest common denominator across a well defined subset of the Linux distros. Ian discussed the LSB roadmap in terms of LSB 3.0, 3.1, 3.2, and 4.0 (targeted for 2008). The LSB is the "umbrella", or delivery vehicle, for standards developed by Linux Foundation workgroups. All LF workgroups will produce standards in a common "LSB module" format.

New Process Model

Tom Hanrahan led a presentation/discussion on the new process model for Linux Foundation workgroups. See "Linux Foundation Business Process" above. Combining the focus of OSDL workgroups with FSG workgroups, the intent is to leverage the strengths of both to create something that is more than just the sum of its parts. Combined focus offers end-to-end value in promoting, protecting and standardizing Linux. The new model calls for advisory councils (vendor, users, developers), open workgroups, and the LSB. With open workgroups, there was discussion about value for members in the LF. At least some of the value will be in the vendor council, a member-only group which will meet regularly and participate in creating and staffing workgroups.

Transition Plan

John Cherry led an ad hoc discussion with the leaders of the existing OSDL workgroups in transitioning to the LF workgroup model. Some workgroups will move into the new model (DTL, MLI, CGL), while the DCL will probably break up into technical workgroups (drivers, virtualization, RAS). Transition items discussed:

• The groups site will be going away. LF working groups will have at least one open mailing list and a wiki for online collaboration. Document management will be handled by the wiki, but we will be looking into some form of document control as well. The Amember tool will be handling membership information, but with open workgroups, membership is really not an issue for participation.
• All workgroup mailing lists will be open. There was some discussion that this may keep member companies from being able to communicate freely on these lists (not wanting to show up in slashdot, etc.). However, the decision was to start all these lists as open lists and create closed lists if absolutely necessary. It is a lot easier to start with open lists and create closed lists as needed than to open up a list that was initiated as a closed list.
• Mail archives and documents from the OSDL workgroups will be saved, but will not be opened up for public consumption. The content of these archives and documents were generated under the participation agreement and may contain sensitive information for participating companies. Workgroup documents which were made public will migrate over to the new model and remain public.
• Governance of the new workgroups will be determined by the individual workgroups. Groups will be encouraged to keep it simple.
• The OSDL groups generally had a steering, marketing, and technical group. The FS groups will be encouraged to keep together as a single group and to keep the structure simple.
• The user advisory council will be composed of IT, end users, carrier/NEP, and adopters of Linux. It will initially be seeded with LUAC members. We talked about large corporations that could be considered vendors as well as users. Some individuals wear different hats and are vendors to some and users for another. We decided that if your role in your organization was as a user or adopter, you could participate on the user council.
• The vendor advisory council will be a member-only group. It is likely that the vendors will have focus groups such as server, desktop, and embedded. The collaboration infrastructure (mailing list and wiki) will be set up for the vendor advisory council, but we have not yet determined the criteria for being on this council. For instance, company X could send 20 people to the board. It will likely be that participation on the vendor council will be representative based and likely be one or two representatives from each company.
• The Developer Advisory Council will be seeded with the current TAB members. However, it was determined that it would be good to include representatives from other developer communities as well (desktop, application, etc.).
• LF workgroups need to develop a charter to describe both perpetual activities as well as discrete deliverables and workgroup spinoffs.

Action Items

• DCL workgroup: Create and staff workgroups for drivers, virtualization, and RAS.
• DTL/MLI/CGL workgroups: Create LF workgroup, determine governance, develop a charter, and move ahead.
• John/Tom: Create collaboration infrastructure (mailing lists, wikis, fund repositories, etc.) for councils (vendor, user, developer) as well as the LF workgroups (desktop, mobile, carrier grade, drivers, virtualization, RAS).
• John/Tom: Work with each of the existing workgroups to assist in the transition to self-sustaining, self-governed workgroups.
• John/Tom: Announce the new LF workgroups in the appropriate forums.
• Dan/Amanda: Put the remaining collaboration infrastructure into place (membership tracking, document control, calendaring, etc.)