From Fedora Project Wiki
 
(31 intermediate revisions by 4 users not shown)
Line 1: Line 1:
'''NOTE: this is a preliminary draft and likely to undergo significant change'''
= Quick Summary =
= Quick Summary =


Line 18: Line 15:
= Target Products =
= Target Products =


We propose that the current "default offering" be replaced with three distinct operating systems: Fedora Workstation, Fedora Server, and Fedora Cloud. These will inform our overall planning and marketing of Fedora, and guide our allocation of resources. The following targets and purposes are the initial guiding statements; fully-developed versions will be the first deliverables for product working groups as described below.
We propose that the current "default offering" be replaced with three distinct products: Fedora Workstation, Fedora Server, and Fedora Cloud. These will inform our overall planning and marketing of Fedora, and guide our allocation of resources.
 
= Change to Primary Architecture Definition =
 
Primary architectures must target at least one of the Fedora OS products, but do not need to produce all three. For example, an ARM cloud image does not yet make sense, and were s390 to be a primary arch, it might be server only. On the other side, we might  drop 32-bit x86 server. Secondary architectures may just publish a collection of packages and not attempt to target any product at all.
 
= Base Design =
 
This is the common base on which the Fedora OS products will be built. Language stacks and environments will be able to assume that this is available and consistent across all of Fedora, and that change will be carefully managed.
 
The Fedora.next proposal suggests that this should exist, but leaves open exactly what it will look like. This group will create a reference document that answers that question, and work on the practical infrastructure for building this as a subset of Fedora.
 
= Environments & Software Stacks =


== Fedora Workstation ==
We will also develop policies for software in what will become "ring 2". Currently, the Fedora Packaging Guidelines apply to all software; we need guidelines for how software may be included under the Fedora umbrella without necessarily conforming. This group will create those guidelines and work to enable new ways of doing things on top of the Fedora base.


* Target audience: Linux users who want to be running Linux; developers, sysadmins and other IT professionals; Linux enthusiasts at universities; "makers" and content creators.
We want to allow disruptive innovation without disrupting what works in Fedora now; this group will help manage that. At first, work will be concerned with more conservative approaches like the first generation Software Collections (which may fit in with only minor exceptions to the current packaging guidelines), this is also the place to explore and solve issues like container composition and updates.
* Purpose: Keep Linux users on Fedora and attract new users in this niche.


The traditional desktop is a shrinking market, as more general users move to mobile platforms. Even if we change our software, Fedora is not well-positioned to attack the tablet or phone-computing markets. However, there will continue to be users who require or want a desktop operating system, and a significant portion of these technical users will want to run Linux. We recognize that this is and will always be a niche, but we want Fedora to serve this niche well.
= Working Groups =


== Fedora Server ==
Working groups will be independent sub-committees of FESCo with membership selected by FESCo from community volunteers.  The working groups will be tasked with the practical next steps of this proposal.  There will be at least one FESCo member in each to act as a liaison.  There should be a liaison with the QA, rel eng, docs, marketing, and web/infrastructure groups as well although these may not be people from those teams but people tasked with facilitating dialogue between those groups and the working group instead.


* Target: People for whom RHEL and CentOS don't move fast enough; people who want to see and influence the future of RHEL.
The Working Groups will have certain elements in common with the Fedora Packaging Committee and with the (currently inactive) Fedora Engineering Services group.  They will be tasked with both creating policies and guidelines around their specific area and with implementing the tooling needed to fulfill those goals. Working groups will be empowered to make decisions independently within their areas; FESCo is responsible for resolving any issues which impact more than one target product.
* Purpose: Fill space left by RHEL's slower refresh; build a better RHEL; engage customers in development of RHEL, OpenStack, and other emerging technologies.


Although many people and organization do run Fedora in production server environments, our messaging in this area has historically been terrible. Myths outnumber facts; having a specific Fedora Server product will allow us to better tell people about what we actually can offer, and to adjust that offering based on feedback from a user community which we serve poorly now.
These Working Groups may draw on the membership of existing SIGs (for instance, the Cloud Working Group may heavily utilize active people from the Cloud SIG to achieve their goals) but the role of SIGs in Fedora is a bit different than the Working Groups. SIGs are informal collections of people with a common interest who can discuss ad hoc issues together.  The working groups are intended to be more focused on defining formal objectives for their areas and then achieving those goals.  


It is not part of the immediate proposal, but we may want to explore a longer lifecycle for the Fedora Server product.
The following Working Groups will be created:


== Fedora Cloud ==
* Product Working Groups
** '''Fedora Workstation'''
** '''Fedora Server'''
** '''Fedora Cloud'''
* '''Base Design Working Group'''
* '''Environments & Software Stacks Working Group'''


* Target: Development; DevOps in production; OpenShift
= Post-Approval Responsibilities =
* Purpose: Address emerging market which we do not currently cover well.


This product is a cloud guest image. It differs from Fedora Server in the need for hardware support, but beyond that, Fedora Cloud OS will also be the primary point for development of a system of pluggable software stacks. Separating from the Server OS allows us the freedom to address newer models for software deployment without getting in the way of more conservative requirements.
If this proposal is approved by the Board, next steps will need to be taken by the following groups.


= Change to Primary Architecture Definition =
== FESCo ==
FESCo will be responsible for facilitating the creation of the product-specific working groups, helping them to produce a charter and selecting their initial membership. FESCo will also will coordinate communication and scheduling between the working groups, and help resolve conflicts where necessary.


Primary architectures must target at least one of the Fedora OS products, but do not need to produce all three. For example, an ARM cloud image does not yet make sense, and were s390 to be a primary arch, it might be server only. On the other side, we might  drop 32-bit x86 server. Secondary architectures may just publish a collection of packages and not attempt to target any product at all.
== Product Working Groups ==
The first responsibility of each working group will be to establish a governance charter.


= Working Groups =
Then, the first required deliverable for each group will be a Product Requirements Document. This will include a statement of target audience and the role the product is intended to fill in the Fedora ecosystem. This document will be presented to the Board for ratification.  These should be done by January, 2014.


Several working groups will be tasked with the practical next steps of this proposal.  
The second deliverable should be a list of necessary changes from existing Fedora procedures needed to release the product.  This should be ordered to show what things depend on other changes and at which point the changes will mean that we can no longer produce the current type of Fedora.  This will allow us to identify the resources needed by what teams in order to implement the plan and at what point we may need to have a longer than normal release cycle to do tooling work.


In the existing Fedora terminology, SIGs are very informal, and may eventually graduate to "Projects", although most do not. Currently, Cloud, Desktop, and Server all have Fedora communities at the SIG level, at various levels of involvement. Going forward, we will create Project-level groups for the three products outlined above, with formalized objectives, membership, and governance.
The last deliverable is to actually start producing the Fedora Products listed here. The list of necessary changes generated as the second deliverable describe the intermediate steps to achieve that goal.


Like the existing Fedora Packaging committee, each group will be an independent sub-committee of FESCo, with membership selected by FESCo from community volunteers, with at least one FESCo member in each to act as a liaison.
== Release Engineering ==
Release engineering's first deliverable will be a high-level overview of tooling changes needed to deliver these new products, as well as to identify potential resourcing issues.


== QA ==
Fedora QA's first deliverable will be to work with each of the Product Working Groups to define a set of Release Criteria appropriate for that product. The proposal should include any resource issues around testing and automation.


* Product Projects
== Websites ==
** '''Fedora Workstation'''
The "Get Fedora" website will need significant redesign. We will also want landing pages and brochure site for each of the Fedora products.
** ''Fedora Server''
** ''Fedora Cloud''
* ''Base Design'': define the common base on which the Fedora OS products will be built
* ''Environments & Software Stacks'': develop and maintain policies for software in what will become "ring 2". Currently, the Fedora Packaging Guidelines apply to all software; we need guidelines for how software may be included under the Fedora umbrella without necessarily conforming. This group will work with and alongside the FPC, but be independent of it.


= Conclusion =
== Documentation ==
We will need a plan for how documentation is and is not shared between products. Each product will certainly have at least some amount of individual documentation. Other documentation may need to be updated to clarify target audience and platform expectations.


WRITE CONCLUSION
== Marketing ==
This represents a significant shift in marketing strategy. Marketing each Fedora product independently is fundamental to the proposal, and a plan for doing that marketing will need to be developed.

Latest revision as of 18:55, 6 September 2013

Quick Summary

  • Make three separate products (Fedora Workstation, Fedora Server, Fedora Cloud) to fit specific target needs as defined by the Fedora Project. Focus our planning, development, and marketing on these products, but also make it easier for community members to produce alternatives.
  • Define a common core which these products and alternatives can rely on. Aim to provide interface stability to outer levels, while allowing well-coordinated progress.
  • Make it easier for software to be part of the Fedora universe without being in one of the Fedora OS products or even in the distribution itself. Standards for software in "ring 2" may be less stringent and offer fewer guarantees.

Background

I hope everyone has seen my "Fedora Rings" talk as presented at Flock and discussed on the development list. This proposal combines those ideas for Fedora policy with a practical product strategy (originally from Stephen Gallagher, but like the rings idea, based on and refined through discussion with many others).

FESCo is interested in developing the practical implementation of these plans, and as they clearly involve strategic direction, we also want to make sure that the board is (um) on board. So, this proposal covers a brief technical introduction to our current plan, and describes a framework for building its practical implementation.

In that past, we have made Fedora from one big collection of packages all treated identically, except for additional QA coverage of "critical path" largely based around system installation. The previous attempt to define a "default user" and "default offering" became diluted by a pull to be all things to all people. That approach has not worked. Instead, we want to focus on three well-defined use cases, while also making the tools we use to build products for those cases available to other interests in the Fedora community.

Target Products

We propose that the current "default offering" be replaced with three distinct products: Fedora Workstation, Fedora Server, and Fedora Cloud. These will inform our overall planning and marketing of Fedora, and guide our allocation of resources.

Change to Primary Architecture Definition

Primary architectures must target at least one of the Fedora OS products, but do not need to produce all three. For example, an ARM cloud image does not yet make sense, and were s390 to be a primary arch, it might be server only. On the other side, we might drop 32-bit x86 server. Secondary architectures may just publish a collection of packages and not attempt to target any product at all.

Base Design

This is the common base on which the Fedora OS products will be built. Language stacks and environments will be able to assume that this is available and consistent across all of Fedora, and that change will be carefully managed.

The Fedora.next proposal suggests that this should exist, but leaves open exactly what it will look like. This group will create a reference document that answers that question, and work on the practical infrastructure for building this as a subset of Fedora.

Environments & Software Stacks

We will also develop policies for software in what will become "ring 2". Currently, the Fedora Packaging Guidelines apply to all software; we need guidelines for how software may be included under the Fedora umbrella without necessarily conforming. This group will create those guidelines and work to enable new ways of doing things on top of the Fedora base.

We want to allow disruptive innovation without disrupting what works in Fedora now; this group will help manage that. At first, work will be concerned with more conservative approaches like the first generation Software Collections (which may fit in with only minor exceptions to the current packaging guidelines), this is also the place to explore and solve issues like container composition and updates.

Working Groups

Working groups will be independent sub-committees of FESCo with membership selected by FESCo from community volunteers. The working groups will be tasked with the practical next steps of this proposal. There will be at least one FESCo member in each to act as a liaison. There should be a liaison with the QA, rel eng, docs, marketing, and web/infrastructure groups as well although these may not be people from those teams but people tasked with facilitating dialogue between those groups and the working group instead.

The Working Groups will have certain elements in common with the Fedora Packaging Committee and with the (currently inactive) Fedora Engineering Services group. They will be tasked with both creating policies and guidelines around their specific area and with implementing the tooling needed to fulfill those goals. Working groups will be empowered to make decisions independently within their areas; FESCo is responsible for resolving any issues which impact more than one target product.

These Working Groups may draw on the membership of existing SIGs (for instance, the Cloud Working Group may heavily utilize active people from the Cloud SIG to achieve their goals) but the role of SIGs in Fedora is a bit different than the Working Groups. SIGs are informal collections of people with a common interest who can discuss ad hoc issues together. The working groups are intended to be more focused on defining formal objectives for their areas and then achieving those goals.

The following Working Groups will be created:

  • Product Working Groups
    • Fedora Workstation
    • Fedora Server
    • Fedora Cloud
  • Base Design Working Group
  • Environments & Software Stacks Working Group

Post-Approval Responsibilities

If this proposal is approved by the Board, next steps will need to be taken by the following groups.

FESCo

FESCo will be responsible for facilitating the creation of the product-specific working groups, helping them to produce a charter and selecting their initial membership. FESCo will also will coordinate communication and scheduling between the working groups, and help resolve conflicts where necessary.

Product Working Groups

The first responsibility of each working group will be to establish a governance charter.

Then, the first required deliverable for each group will be a Product Requirements Document. This will include a statement of target audience and the role the product is intended to fill in the Fedora ecosystem. This document will be presented to the Board for ratification. These should be done by January, 2014.

The second deliverable should be a list of necessary changes from existing Fedora procedures needed to release the product. This should be ordered to show what things depend on other changes and at which point the changes will mean that we can no longer produce the current type of Fedora. This will allow us to identify the resources needed by what teams in order to implement the plan and at what point we may need to have a longer than normal release cycle to do tooling work.

The last deliverable is to actually start producing the Fedora Products listed here. The list of necessary changes generated as the second deliverable describe the intermediate steps to achieve that goal.

Release Engineering

Release engineering's first deliverable will be a high-level overview of tooling changes needed to deliver these new products, as well as to identify potential resourcing issues.

QA

Fedora QA's first deliverable will be to work with each of the Product Working Groups to define a set of Release Criteria appropriate for that product. The proposal should include any resource issues around testing and automation.

Websites

The "Get Fedora" website will need significant redesign. We will also want landing pages and brochure site for each of the Fedora products.

Documentation

We will need a plan for how documentation is and is not shared between products. Each product will certainly have at least some amount of individual documentation. Other documentation may need to be updated to clarify target audience and platform expectations.

Marketing

This represents a significant shift in marketing strategy. Marketing each Fedora product independently is fundamental to the proposal, and a plan for doing that marketing will need to be developed.