Fedora Workstation PRD
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.
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.
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
While the developer workstation is the main target of this system and what we try to design this for, we do of course also welcome other users to the Fedora Workstation. 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 want a system with a productivity suite to write their papers will of course get benefit from the fact that we do ship a good productivity suite. We will welcome feedback and request from all our users and try to accommodate it as long as it doesn't negatively impact our developer target group and we have people available who have the time and ability to work on the requests.
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
The working group will develop guides and style recommendations for applications that target the workstation. These guidelines will be mandatory for the core apps that are specifically developed for the workstation, but 3rd party software developers will be encouraged to follow them too.
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.
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.
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.