Fedora.NEXT at FOSDEM and DevConf

I just want to throw out a quick update on the progress of Fedora.NEXT work.

First of all, the deadline for the submission of the Workstation, Server and Cloud PRDs was extended one week, so they will now need to be delivered by Monday, January 20th. Assuming that the PRDs are ratified by the Fedora Board and FESCo, that means that the next phase will be execution planning.

Execution planning means that we will need to put together a list of resource needs of all varieties (for packaging QA, doc-writers, release-engineering, Ambassadors, etc.). This will also include scoping efforts to determine the delivery schedule.

This is a big task and one that will need help from throughout our community. I’ve reserved time at two of the larger upcoming European FOSS conferences to get people together and brainstorming these needs.

The first such conference is FOSDEM, the Free, Open-Source Developers European Meeting in Brussels, Belgium. I have reserved an hour meeting in the “distributions” devroom on Saturday, February 1 at 1600 local time for this purpose. If you are attending FOSDEM and have any interest in seeing Fedora succeed, I urge you to join us there and help turn these goals into actionable efforts.

The second conference is Devconf.cz, running a week after FOSDEM in Brno, the Czech Republic. Devconf is a very Fedora-friendly conference and will be dedicating an entire day to the Fedora Project: Sunday, February 9th. Matthew Miller, Fedora’s Cloud Architect, will be kicking off the Fedora Day with his keynote entitled “Fedora.next: Future of Fedora Big Picture, plus Working Group report“.

Following Matthew’s keynote, I will be leading a workshop/brainstorming session in the same room entitled “We are Fedora (and so can you!)“. The goal of this session will be similar to that of the FOSDEM devroom session: to get as many people with an interest in Fedora into the same room to help us plan how to meet the visions set forth in the Fedora product PRDs.

If you are going to either of these conferences, I very much hope you will join us!

Proposal: FreeIPA Role for Fedora Servers Using Cockpit

At last week’s Fedora Server Working Group meeting, we encountered some confusion as to what exactly a role should look like. We seemed to be of differing opinions, technologically, on how to implement the roles. I recommended that we take a step back and try to design the user experience that a role should accomplish first. I recommended that we probably wanted to take one example and provide a user story for it and use that as a straw-man to work out the more general cases of server roles.

Continue reading

IETF, MTI codecs and Fedora

Background

Cisco announced that they will be releasing an implementation of H.264 under a BSD license along with distributing binaries to encode and decode this video format. Their purpose for doing so is to push it as a WebRTC standard with the IETF. The problem faced by Fedora is that the patent licensed granted by Cisco covers only the binaries that they themselves build and distribute. If the IETF approves the use of H.264 in addition to (or instead of) the VP8 codec as part of mandatory compliance in the WebRTC standard, Fedora would have to ship (or provide access to) a pre-compiled binary codec over which we have no control. We cannot ship a version that we ourselves build because it would not be covered under the patent license grant.

Fedora’s Response

The issue was escalated to FESCo, the Fedora Engineering Steering Committee, today with the question of how we should respond. We elected to make the following statement[1]:

Fedora is a distribution that cares about software freedom and our users
freedom. Firstly, we cannot ship binary-only prebuilt software within Fedora.
This rules out inclusion of OpenH264 binaries direct from Cisco, or other
providers. Secondly, we cannot ship software built from source which is not free
for any use, freely distributable, and free from patent restrictions.
Therefore, Fedora is similarly unable to ship rebuilt OpenH264 code.

Fedora would be much happier with a non-patent encumbered codec in the standard
as it would relieve us of the burden of caring for a codec implementation that
we cannot fix if it is buggy on our platform, let us ship improved or more
efficient versions of the codec if that is asked for, and relieve us of the
burden of making sure all implementors of the standard were using a proper
technique to retrieve the patent-encumbered portion from the internet so that
we weren't shipping non-free code.

Acceptance of an insufficiently-free license of the OpenH264 codec would mean
that open-source vendors are not able to implement it on their own terms. They
must rely on the implementation provided by a third party (Cisco) and create
workarounds to have the user download that implementation after installation,
increasing the burden on open-source users. This creates an unequal environment
for open-source vendors.

As members of the Open Source community, we feel that it is necessary to take a principled stand here. Allowing the WebRTC standard to mandate a patent-encumbered codec ensures an uneven playing field for open source distributions. I would like to encourage anyone reading this to write to the IETF at rtcweb@ietf.org and express concern at how much damage it would do to force an insufficiently open codec to be required for compliance with the future of the World Wide Web. Please make it clear to the IETF that to select H.264 as a mandatory codec would be to reduce the availability of competitive and alternative implementations.

[1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg09546.html

Why not change the world?

I have always been interested in science, technology and (most of all) computers. These are things that I always loved, even though they were sometimes difficult. I loved math and science class in school; I read science-fiction and fantasy novels in all of my spare time. I was the nerdy kid at school that was bullied and mocked. It would have been so easy to just give in and be “like everyone else”. I could have stopped reading. I could have played more sports.

But I didn’t. I knew what it was that I loved. I knew that what I wanted was more important than what they wanted. Most of all, I wanted to change the world.

No one in history has ever changed the world by being what others wanted them to be. They have changed the world by daring to laugh at conventional wisdom and try something new. They have changed the world by standing up and defying that “might makes right” or that “going along to get along” is the right course of action.

This is the sentiment that drove me into my open source career. I chose this path in my life because I see it as a way to effect real change in the world. This is a change really has happened in my lifetime and continues to do so. It flies in the face of the history of business.

At its heart, the open source movement is an extension of science. Sir Isaac Newton wrote “If I have seen further it is by standing on the shoulders of giants.”. One of the greatest minds in history acknowledged that his contributions to our greater understanding came not from his sole vision but from the fact that thousands of great and lesser minds had worked together to create a world into which his particular spark could ignite change.

The philosophy of open source is the same. It is a mechanism for enabling thousands of people to work together for a common goal. Classic software development has always occurred in closed environments that jealously protect their secrets. Essentially, it has operated on the same philosophies as invention and manufacturing has over the years. It is a difficult habit to break, especially when it seems like you’re giving something up.

That is the core piece that most people have trouble grasping, in my experience. While you are giving up exclusive control, you are gaining something much more valuable: you’re expanding the base level. You are feeding those giants so that you and others can see further and strive higher still. Where once you were an inventor standing on one giant’s shoulders, now you look down and can see the truth for what it is: that giant is standing on other, bigger giants. And on it goes, all the way (“It’s giants all the way down”, to borrow from a popular joke).

Once that realization is made, things become more clear. When you stand taller and can see further, you realize that your efforts can have greater impact than you once believed. Instead of the miserly hoarding of knowledge, you can share it with the world and see what they will do with it too. It won’t always be pretty and it won’t always match your original intentions, but it will always be greater than the sum of its parts. And in a small way, you will have changed the world.

One thing that gets forgotten a lot of the time when folks talk about changing the world is that they talk about massive shifts in direction. They talk about those moments in history where you can look back and say, “There! That’s the moment when everything changed!”. There will always be a few such moments every few centuries, but the truth is that most change happens glacially.

Open source is one of those glacial changes. I don’t use that term to suggest that it moves too slowly. Rather, I chose it to evoke the immensity, inevitability, and incredible moving inertia that drives it. A glacier may take decades, centuries or millenia to move across the land, but nothing can truly stand against that oncoming tide. This is the legacy of open source: the tide of progress.

Over the last twenty-two years of Linux, we’ve seen a great many strides made in the march of progress. When people ask what I work on and I say “Linux” or “open source”, they often give me a blank look. I usually follow up with the following sentence: “Do you have a device with an on-switch that doesn’t start with the letter I? Chances are, it’s running Linux or at least some open source code”. Every time I say this, I boggle at the magnanimity of it. All those years of hard work from so many talented individuals has paid off to such a degree that open source technologies are now the default, rather than the challenger or also-ran. Moreover, it has become so ubiquitous that the public at large is using it without ever caring or needing to know about it.

In a very real way, the open source community has changed the world. It continues to do so every day. I get to be a part of that, and I won’t pretend that the idea doesn’t make me a little heady and giddy.

I started this blog entry up with the question “Why not change the world?”, but that was a little bit misleading. We’ve already succeeded. The real question has to be “How will you change it next?“.

Flock 2013 Con Report

My god, it’s full of stars!

So as most of you probably know, this past weekend was Flock, the first of a new breed of Fedora conference that replaces FUDCon. It was reasonably well-attended (the count I heard was about two hundred). Among those that attended were nearly all of the well-known members of the Fedora community. I’m sure some (many?) of them will also be summarizing their experiences, but I want to get my notes out there while it’s still fresh. This is not a comprehensive overview of Flock. If that’s what you’re looking for, Máirín Duffy has provided an excellent set of blog posts including the recordings and transcripts[1].

The first three days followed a pattern of talks/lectures before lunch and workshops or hackfests in the afternoon. There were a great many sessions (usually eight or nine running concurrently at any time) and this made it somewhat difficult to see all of the useful content.

There were a great many interesting talks, but I’m going to focus this report on the three that I think will have the most lasting (and widely-felt) impact on the Fedora project as a whole.

Updates Model

The first here was Tom Callaway’s proposal of changing the default updates delivery method. As he put it, currently Fedora users are “drinking from the firehose”. All updates are delivered as soon as they hit the stable updates repository and it feels to users like they are in constant flux. Tom’s proposal is that instead of a constant updates stream, we should shift to delivering important[2] updates as part of a monthly update set. Security issues should still be released in the current model, so that users get those as quickly as possible. There was some debate over whether security updates should be installed automatically or just notified, but that was left unresolved. The set of “important” updates should be rolled up as a bundled collection of updates that is prepared a week before the monthly deliverable and offered for testing as a complete set. Package updates outside this set should be made available similar to the way Microsoft does its “optional” updates. They can be selected manually (or in bulk) in an updates tool if the user wants them. We believe that, by having the ability to tests updates as a set we will be able to reduce some of the instability the arises throughout the Fedora supported lifetime as well.

Tom’s proposal dovetails closely with the next two proposals, one from Matthew Miller and one from myself. Matthew’s proposal is fairly well-known at this point. It involves redefining Fedora into a set of policy rings wherein we can tighten or relax the packaging rules in order to make it easier to run applications and SDKs in or on Fedora. I won’t go into great detail on this proposal, as it’s been discussed at great length on other lists. I will say that the Fedora community as represented by Flock attendees was receptive and very much liked the idea of relaxed packaging requirements at the higher levels of the stack, as well as being able to layer projects atop other foundational pieces (such as OpenShift Gears or Software Collections).

Fedora as Products

The final proposal was one that I came up with and discussed with Robyn Bergeron and the RHEL architects shortly before Flock. The general idea behind this proposal was to stop trying to treat Fedora as “everything for everyone”. Instead of our classic approach of building all projects in Fedora as a single collection of packages, we should instead focus on a set of specific constituencies and serve those needs directly and completely. To that end, I proposed that we should build three products from the Fedora family with very specific target audiences and then work with Matthew’s proposal to layer other software atop these products in a sensible way.

Fedora Server

Target: People for whom RHEL and CentOS don’t move fast enough, and people who want to see and influence the future of RHEL
Purpose: Build a better RHEL, and engage customers in development of RHEL, OpenStack, and other emerging technologies.

One of the key points here is that we would start making it clear that Fedora Server is the development path for RHEL 8. Disruptive changes made to the Fedora Server would be carefully scoped out ahead of time. We want this to be the place that we can engage application developers and tell them “if you want something from RHEL to enable functionality for your application, this is where you build it”.

Fedora Cloud

Target: Development; DevOps in production; OpenShift
Purpose: We do not become entirely irrelevant.
This should be mainly a proper subset of the Fedora Server, with some few additional packages for acting as a virtualization client. The goal here is to provide the definitive operating system for running in a PaaS environment like OpenShift. This is the fast-moving DevOps platform that people who are doing rapid develop-and-deploy with high resiliency would want to use in production.

Fedora Workstation[3]

Target: Creatives, Developers, Sysadmins, and other IT professionals
Purpose: Keep Linux users on Fedora (This is a niche market; we recognize that. But let’s make it our niche.)
This is the platform upon which we would want people to be doing useful work in the Fedora/RHEL ecosystem. It’s where the “makers” and IT professionals should be able to get their work done. This is also the product that would have the most leniency in making disruptive changes (the most obvious forthcoming one being Wayland). That is not to say that this should be “Rawhide in disguise”. The goal here (as with the other products) is that this should be a stable and useful workstation that enables the user. It is not a playground, nor is it a general-purpose desktop.

Tying it together

The responsibility for defining the specific requirements placed upon each of these products would be placed upon a working team (chaired by a FESCo member) for each product. The proposals presented therein would require approval and then would become essentially a constitution for that team. The specific details of how this process would work are still being worked out. All of this is contingent upon acceptance of the overall plan by the Fedora Advisory Board, who will be receiving a formal proposal in the next week or so.

Last Day

The fourth day was dedicated to hackfests. I spent the morning working on Kerberos-related hacking on the fixes for the new kernel keyring support and then the afternoon in Matthew Miller’s “Hack the Future” session discussing his and my proposals for a new, more targeted Fedora design. In this latter discussion, we came up with most of the above plans.

It is worth noting that while the overall reception of these plans was positive and encouraging, there were individuals from Fedora Release Engineering and Fedora Quality Assurance teams that fear these changes will strain their already-limited resources. This is a valid concern and will be addressed. We’re looking at ways to reduce the impact on these two teams (such as by increasing automation and re-using existing capabilities wherever possible) as well as possibilities for providing increased resourcing. No plan will go forward without consulting these two groups.

If you have read this far, I thank you. I know it’s a bit wordy.

Notes

[1] http://blog.linuxgrrl.com/category/fedora/flock/
[2] “Important” should be left intentionally vague at this time.
[3] There is debate over whether to call it “Workstation” or “Client”, but we all agree that “Desktop” is not the right name. I’m in favor of Workstation, so that’s what I’ll use here.

Flock to Fedora!

In just a little over a month’s time, Fedora will be kicking off it’s brand-new annual developer’s conference in Charleston, South Carolina. In the past, Fedora would run two or more regional conferences called “FUDCon”[1] each year. Historically, these FUDCons were run as “unconferences”, where the most devout of Fedora’s community would converge and put together an agenda on the fly during the first day. Starting this year, instead of an unconference format, we’ve opted for developing something a lot closer to the OpenStack Summit. We opened a call for participation several months ago and then had a public voting period to determine which set of proposed talks and hackfests would be scheduled.

This new conference, named “Flock” will be running for four days, from August 9th through the 12th. The plan is to have a keynote each morning, followed by nine concurrent rooms holding one-hour talks until lunch. After lunch, the rooms will be dedicated to hackfests and birds-of-a-feather discussions. The goal of Flock is to be more of a “Do-Con” (described as such by our illustrious Fedora Project Leader, Robyn Bergeron). We want people to come and learn something each morning, then get together in the afternoon and hack on it (either code or conversation). August 12th is reserved entirely for hackfests and is currently unscheduled. If you get a good start on something new and cool at the conference, you can stick around and really hack on it on Monday.

I submitted a number of proposed sessions to Flock and had a total of five (!) selected for inclusion. If my readers would like to stop in and hear what I have to say, you are welcome to come visit any of the following sessions:

These are, of course, not all of the sessions I will be attending (in fact, looking at the schedule, there is not a single time slot where I do not plan to be attending at least one session). The full schedule for Flock looks to be amazing and I think that there will be a great deal of interesting discussion and work done during this long weekend.

[1] “Fedora Users and Developers Conference”, as well as being a play on words (FUDCon: Against FUD)

One Week With GNOME 3 Classic: Twenty-Eight Days Later

True to my word, I have spent the last twenty-eight days running GNOME 3 Classic. For the most part, I have been very happy with it. As I said in my last entry in the original series, I originally expected that I would ultimately decide to switch back to KDE when the experiment was over. Twenty days after my final entry, I have decided to stop using GNOME Classic, but not in favor of KDE.

Continue reading