Fedora.next working groups outline their products

The Fedora project's Fedora.next initiative is a new approach to the construction of the distribution. In late 2013, the Fedora Board proposed assembling three "working groups," each of which would craft its own set of requirements for a distinct Fedora final product: workstation, server, and cloud. The three products would share a common core, but could more easily differentiate themselves in packaging and configuration decisions so that—hopefully—the three product classes would be better served than they are by trying to build a single, monolithic product that meets all needs simultaneously. The working groups have now submitted their Product Requirements Documents (PRDs), so a clearer picture has begun to emerge about what the three products will provide.

Bill Nottingham, writing on behalf of the Fedora Engineering Steering Committee (FESCo), noted on February 4 that all three PRDs had been submitted and accepted by FESCo. They are available on the Fedora wiki (Workstation, Server, and Cloud), as is a PRD from the "Environment and Stacks" working group that lays out an intermediate platform layer on which the three top-level Fedora products will build. The plan also involves a "Base" layer beneath Environment and Stacks, but so far the contents of Base do not seem to be the subject of much debate; presumably they are the well-established core services already used in Fedora.

The three product PRDs share a few common factors, such as specifying target users (and/or use cases) and outlining what further work remains in order to build the final product. But they differ significantly in other respects. For example, the Workstation and Server PRDs do not address specific components or packages to be included, while the Cloud PRD goes into considerable detail about supporting specific application frameworks and orchestration projects (such as Rails, Sinatra, Django, OpenStack, and Eucalyptus).

Workstation

The Workstation PRD is the shortest document of the three, perhaps reflecting Fedora's long history of developing a workstation-friendly distribution. The "Target Audience" section is interesting, if only because the target is explicitly software developers. Four use cases are spelled out, including computer science students and developers working at different sizes of companies. The PRD says that: "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."

Targeting software developers as the primary user segment is a controversial choice to some project members; there was a lengthy debate on that subject in late November 2013. Some felt, for example, that explicitly restricting the target audience to developers was major change, and that Fedora had historically sought to be a desktop platform for a broad assortment of users. Others were not convinced that "developers" was a suitable target audience at all.

The PRD also spells out a set of technical goals. Many, like "robust upgrades," require little explanation or justification. But there are some interesting choices in the list. For instance, the list includes support for container-based application installation—meaning self-contained applications that can be installed (perhaps on a per-user basis), updated, and removed much like mobile apps are on smartphone and tablet systems. That concept was the subject of considerable discussion at GUADEC 2013, so it is interesting to see Fedora adopt it as a goal outright.

The goals also include the ability to upgrade the OS's own packages without disrupting software development—that is, it should be possible to develop a program on a Fedora Workstation that targets something other than the latest Fedora Workstation itself. In other words, development environments should be able to be isolated from the base system. If it is impossible to upgrade Fedora's cURL package and still work on code that needs an older cURL release, developers would not be happy. The goals do not specify certain components, such as whether or not GNOME would be the default desktop environment (a choice which was also the subject of considerable debate on the mailing list).

Otherwise, however, the PRD mostly notes that there are few changes anticipated from the way Fedora is currently developed: the same package formats, repositories, and ISO images that serve Fedora today should work fine on the Workstation product in the future.

Server

Similar to Workstation, the Server PRD does not describe a drastic departure from the way Fedora is currently designed, although there are some points worth noting. The Server PRD's Mission Statement (which for unexplained reasons is a distinct statement from the Server Vision Statement) explains that the project wants to define a base server platform as well as a set of "featured server roles" to address important server scenarios. That is different from the Workstation product plan, which does not involve defining a suite of use cases requiring separate treatment.

There is not yet a list of what these featured server roles will be, but the document enumerates some possibilities: FreeIPA Domain Controller, DNS server, DHCP server, file server, OpenStack Hypervisor, and so on. But the PRD does indicate that featured server roles are intended to be well-defined entities, with each one packaged so that it can be installed as a unit, and with each one providing a stable external API.

Getting to that goal will obviously require a lot of additional discussion, not to mention further work. The featured server roles need to be defined, the appropriate packages and configurations chosen for each, and the resulting meta-package implementation built and tested. The PRD notes that each featured server role will need a maintainer to coordinate its development and serve as the point of contact.

The cloud

The Cloud PRD is far and away the longest of the three product PRDs. This is probably not surprising to most, since cloud image deployment is an area where Fedora has traditionally lagged behind other distributions (statistics for this sort of metric are notoriously hard to verify, but Ubuntu, Debian, and CentOS are usually cited as the most common Linux cloud instance options).

The Cloud product will entail some differences from traditional Fedora releases, including making releases available as a machine image (the PRD lists Amazon EC2's Amazon Machine Image (AMI) as the first target format) and distributing it through different channels (in the case of AMIs, through the Amazon Web Service marketplace).

Updates and customizations are another difference; while the document says that Fedora will likely release periodic updates to the Cloud AMIs, it will also need to maintain a new set of tools for users to customize and build their own cloud images—either for use on cloud services other than EC2, or simply to customize the image's content. As mentioned earlier, the Cloud PRD lists a number of application frameworks it expects to support. Though not exhaustive, the list includes frameworks using Ruby, Python (2 and 3), PHP, Node.js, Java, Perl, and Go. Several other applications, such as Hadoop and OpenShift, are also mentioned along the way.

The PRD also lists eleven cloud services and environments it would like to support (OpenStack, Eucalyptus, Apache Cloudstack, OpenNebula, oVirt, Amazon EC2, Google Compute Engine, HP Cloud, Rackspace, Digital Ocean, and Linode), and its interest in supporting private clouds, public clouds, and hybrid setups. That is already a lengthy list of deployment scenarios on which the Fedora Cloud project will need testing, but the PRD also outlines an interest in serving as a base for cloud orchestration, distributed database management, and other higher-level functions.

Fortunately, the working group does seem to be aware of the rather large scope that these requirements make up. The initial target will be more limited, with EC2 images for Intel-based machines designed to run as single servers.

In addition, the PRD sets out a list of intermediary goals that need addressing. The first is reducing the size of the image footprint, followed by support for the Docker application container format, tools for building and deploying cloud images, developing software stacks for the various frameworks to be supported, and more.

The Cloud PRD is quite ambitious, especially when compared to the Workstation and Server equivalents. Now that FESCo has accepted all three, it will be interesting to see how the concrete plans for each of these products take shape. The Workstation product will likely demand the least, while the Cloud product could take shape over the course of several Fedora releases. But, as Fedora attempts to redefine itself in these more specific roles, having a clearer game plan is certainly the right first step.