Workstation/Workstation PRD

Fedora Workstation PRD

This page includes the original Fedora Workstation PRD from January 2014. It has been replaced by a new PRD.

Mission statement

The Fedora Workstation working group aims to create a reliable, user-friendly and powerful operating system for laptops and PC hardware. We want to create a stable, integrated, polished and user friendly system that can appeal to a wide general audience. The Fedora Workstation working group will have a special focus on providing a platform for development of various types of applications. This PRD is not meant to be an exhaustive list of what potential users can or will use the Fedora Workstation for, but rather outline the Workstation working groups development priorities and overall goals. We want the Fedora Workstation platform to be attractive to a range of developers types - from hobbyists and students to developers working in a corporate environments. This is meant to be a living document which evolves along with the project and which can be changed as time go on by the workstation working group.

Target Audience

General:

Programming Environment: web languages and tools, open source databases, IDE, Compilers, debug tools, performance monitoring

Desktop apps should be sufficient to make this system the user's only computer. Users should not be required to be familiar with the terminal or to use the terminal for essential tasks, including software development.

Case 1: Student

Engineering/CS student who needs a personal system for software classwork and personal projects. Software class work may require particular tool chain versions. Tries out new versions of open source applications when released. Uses computer to play games. Ability to play 3D games from commercial publishers distributing games for Linux. Multiple developer environments i.e. school standard for class work, latest tools for personal use.

Case 2: Independent Developer

Personal development system for an independent software developer doing contract work or developing apps for a new opportunity.

Desktop Apps: Up to date desktop with email client, browser, productivity suite, messaging, and a complete set of desktop apps and utilities. Desktop apps should be sufficient to make this system the developer's only computer.

Generally a single development environment with the latest web development tools.

Easy to configure Virtual Machines for testing software.

Case 3: Small Company Developer

Software developer working on an individual project or coordinated small team. DevOps.

Generally a single development environment with the latest web development tools. Easy to configure Virtual Machines for testing software.

Testing in local VMs and on dedicated testing systems.

Case 4: Developer in a Large Organization

Software developer working on a large, coordinated project in a large organization.

Support for enterprise login. Multiple developer environments i.e. current project and maintenance work on older projects. Testing typically on a target system in a testing lab.

Other users

While our focus is on creating a top-class developer workstation, our developer focus will not compromise the aforementioned goal to be a polished and user friendly system that appeals to a wide general audience. In fact, many of the changes and improvements we expect to implement for developers will be equally beneficial to other user segments. For instance our plans around multi-screen handling and improved terminal functionality should also be highly beneficial to a system administrator. Or the work we are doing to provide a high performance graphics workstation would be useful to people who want a Linux gaming PC. Or a student who just wants a system with a productivity suite to write papers will of course get benefit from the fact that we do ship a good productivity suite. We welcome feedback and requests from all our users and will consider accommodating it when possible.

Overall plans and policies for the product

Technical goals and design principles:

• Robust Upgrades

Upgrading the system multiple times through the upgrade process should give a result that is the same as an original install of Fedora Workstation. Upgrade should be a safe and process that never leaves the system needing manual intervention.

• Encapsulation of development environments

In general, development environments should allow targeting deployment environments that are different than the operating system itself, and an upgrade to a newer version of Fedora Workstation should not mean that a coding project needs to be modified to work with new versions of libraries and runtimes.

• Quality releases

We want to focus on engineering practices that ensures that the core product offered is of the highest quality possible. This includes keeping the core test matrix as small as possible a high degree of testing automation and collaborating with upstream to increase general test coverage of core modules.

• Better upgrade/rollback control

If there are any problems with an upgrade or an upgrade breaks a configuration script we want to offer an easy way for users to roll-back such upgrades and changes.

• Container based application install

The working group will investigate and work with the other products to decide and work on the possibility of a system where applications can be installed inside a container to improve security and simplify compatibility through library bundling.

• 3rd party software

Fedora Workstation will work to ensure that 3rd party software has a stable underlying OS with a known set of APIs/services that ISVs and other developers can rely on for their software. Fedora will not include any non-free software by default or host any non-free software in our repositories.

• Fedora ecosystem integration

While the workstation will have a different target than the Server and Cloud images it is still important that the 3 variations share technology and infrastructure. The 3 systems will all be RPM based and while for instance the open source databases will be packaged primarily with the Server in mind we want to be able to pull them into the developer workstation too.

• Work towards standardizing and unifying the Linux desktop space

We want to use and develop technologies that can be widely shared with the rest of the community and we want to allow developers to use the tools they prefer for their application development yet make them all feel like a natural fit into our integrated desktop experience. This would include items like theming and making sure we offer a consistent accessibility story across different development toolkits. The product will reach out and collaborate with the Fedora Design team and other relevant groups on such items.

• Develop application guidelines and designs

Fedora Workstation follows the GNOME Human Interface Guidelines. These guidelines are mandatory for applications installed by default. Third-party software developers are encouraged to follow them too.

• Delivery Mechanism

The Workstation product plans to leverage the existing image/repo delivery mechanisms already present in Fedora. The product will be offered for installation via either live or netinstall ISO images.

Core Platform Components

The Workstation working group will define a set of packages that are considered required be installed in order for the system to qualify as a Fedora Workstation. Through policy users will be strongly advised against uninstalling any of these packages and there will also be no option in the graphical software installer to uninstall them. Any optional packages for the Fedora Workstation can not obsolete or in any other way try to remove or disable these packages.

These installed packages will together form the basis of the API and service promises the system makes to 3rd party developers.

The Fedora Workstation working group will also define two set of requirements, one for anything that is to be considered for inclusion in the core platform components list and one for optional packages. This will include a requirement to support specific system services and libraries, for example the working group might make it a requirement that any software that wants to be part of Fedora Workstation can run against Wayland or directly output sound to Pulse Audio.

The working group will also specify policies in terms of branding, theming and desktop graphics, although these items will of course need to be in line with the overall Fedora branding guidelines and styles.

Work Model

We will at any given time try to have one major engineering effort underway for the Fedora Workstation. The definition of a major engineering effort is something that requires changes in a wide set of packages and tools. At the same time we will be working on smaller projects to improve various aspects of the distribution and also setting things up to be ready for the next major effort. We will try to announce and plan these things well in advance, by putting up a public timeline. Of course resources and changing market conditions might make changes to the plans necessary on an ongoing basis.

Marketable Features

Each release is to have at least one item developed for it that we present as a 'developer feature'. These items might be small or large in terms of the effort behind them, but they will be a core part of our messaging of being a great first choice for developers. Examples include Software collections, Developer Assistant, LinuxApps, new features in Boxes, IDE integration and so on.

Other tasks for working group

The working group will also be responsible for on-going feedback and suggestions on release schedules, based on collaboration with upstream components, the other Working Groups and FESCo, and Fedora Infrastructure. The working group will also regularly meet with a designated representative of Red Hat to discuss how Red Hats product and development plans will affect the Fedora product development and resource allocation.

Packaging for the Workstation

The working group hopes and expects that there will continue to be a wide range of software, packaged and maintained by the wider Fedora community, software that will available for install through the desktop Software installer. A lot of this software might not have any direct relevance to the main goals of the product or working group, but that is not a problem or something that the working group wants to discourage. No software will be blocked from being packaged as long as it doesn't break any part of the core workstation system upon install.

Document Approval

Edits done by Josh Boyer based on FESCo questions/feedback on January 28, 2014.

This was approved by the Workstation WG on January 21, 2014. The final vote was +1:6, 0: 3, -1: 0.

Updated on June 9, 2015 based on consensus of the WG.