Fedora.next in 2014 -- Big Picture and Themes

[Matthew Miller]

On Sat, Jan 25, 2014 at 12:39:53PM +0100, Thorsten Leemhuis wrote:
> Understood, but OTOH it makes me wonder if Fedora.next is a step to
> big and needs to be split or something.

Well, in practical implementation, it probably _will_ be done as incremental
steps. For example, there's the possibility of decoupling the schedules of
the base release from the products, but one of the few solid decisions we've
already made is that that won't happen for F21.

> point is needed obviously. But sometimes I miss a few introductions
> words on the "why" we want all of that and how it's supposed to make
> Fedora better. But that's obviously meta/abstract again, which I

So, here's some things I see.

* Fedora's drift towards being primarily a desktop OS (with other use areas
  considered secondarily if at all) ends up practically restricting uses
  which people really do want Fedora for. That's bad for people who want to
  use Fedora in innovative ways in server and cloud environments. Even
  though we have a lot of sysadmin users and there are many examples of real
  Fedora in production server environments, every time over the past decade
  that someone has tried to figure out what Fedora Server might actually
  mean, it's gotten stalled. This has left many sysadmins feeling like
  either Fedora isn't a place that they can meaningfully contribute, or else
  that their job is to be the Voice of No. Even when one doesn't want to
  just be the project's "stop energy", it sometimes felt like there was no
  other option. Fedora.next should *give* that option for postive
  contribution.

* Although it's certainly not the only reason, Fedora as _solely_ a hobbyist
  desktop is not ideal for an upstream for RHEL server and cloud products.
  That doesn't mean that there isn't room for one, but if we would focus
  Fedora on just that, we'd become increasingly irrelevant to our biggest
  downstream -- and to the project sponsor. (And make no mistake -- that
  concern of mine comes from a point of view of caring about Fedora first,
  not just my employer, because we benefit from taking part in that whole
  ecosystem cycle in ways beyond just Red Hat's direct employee and monetary
  contributions.) One particularly underserved area for Fedora is RHEL
  customers who would benefit from Fedora in some key areas (possibly even
  in production!), as well as those who are interested in experimenting with
  and possibily even shaping the future of the downstream.

* General trend in Linux towards the base distribution being "boring" and
  not mattering. I asked several dozen different people at a gigantic Amazon
  conference why everyone was using the distribution they chose instead of
  Fedora, and the answer was almost universally "oh, I don't care; that's
  not really an interesting question because there's nothing important at
  that level". Now, that might not be really _true_, but it's definitely an
  increasing perception. How can we either fight that perception, or make
  sure that Fedora expands to also do work in the "interesting" space?

* Difficulty building things on top of Fedora. This means both end-users
  with their own applications and bigger more complicated applications like
  OpenStack which it would be nice to have in the Fedora universe. There is
  value in the perfect-crystal-castle-of-all-packages approach, but if we
  build that in one place while everyone is going by on the highway, we're
  not really fulfilling our mission of leading free and open source software
  -- we're doing cleanup from behind and not making the impact we could be.
  I strongly believe that we can make room for this in the Fedora Project
  overall, even for things that are not appropriate in the Fedora
  *distribution* in its traditional sense.

* As you mentioned in an earlier thread, it would be nice if we could make
  it easier to contribute minor changes, including big changes to more
  obscure packages. We can't just be Wikipedia and allow anonymous editing
  of packages (for one thing, we don't have an easy rollback mechanism and
  consequences could be much more severe), but maybe we can find a way of
  loosening things up for the fringes -- maybe even a really large fringe --
  while keeping the core distribution under closer care. (Going way back to
  last summer's discussion, the problem with the former distinction between
  Core and Extras was that Core wasn't really open and the distinction was
  based on who you worked for; I'm quite certain we won't make that mistake
  again. Also, the standards for Extras were higher than those for Core,
  which was of course backwards and an example of community showing the way.
  But all that doesn't mean that we can't take the lessons and do it right.)

* Wanting to eat our cake and have it too when it comes to balancing
  innovation and change management. In order to move fast while not breaking
  everybody all the time, it helps to break things up into larger logical
  segments than just packages. This helps draw out exactly what we really
  care about not breaking, what all might need to change together, and
  allows us be clear about what amount of breakage is an acceptable
  exchange.

So that's some of my thoughts. More later -- gotta take the kids to the
dentist now. :)

-- 
Matthew Miller    --   Fedora Project    --    <mattdm at fedoraproject.org>