Fedora is one of these interesting efforts in community organization that somehow results in a finished product. There are many good things about Fedora as a place to see new technologies and to participate in Open Source. But there are also some bad things that need work. Not all of the technologies are instantly useful or necessary to all users, and they are often adopted quickly, whereas it would often be better (in my opinion) to pursue full integration over a (slightly) longer period of time. We don’t have a clear vision for who users are, or what they want, and collective Laissez-Faire organizing only works to a point, a point at which you need to have strong-willed steering of the ship you’re on to make sure it goes where it needs to get to. And the 6 month release cycles are far too frequent in my opinion if they will result in only a one year overall lifetime.
Specific things I want to see from Fedora:
1). Slow the updates. 800 updates after installation is bordering on insanity. I’d like to see updates only for security issues and bugs (but just those bugs, not wholesale rebases to “fix” a bug and introduce ten more), and I’d like the extreme opposite of what we’re seeing now, but I’ll take what I can get. This isn’t Enterprise vs. non-Enterprise. This is sanity vs. non-sanity. Rawhide is where “stuff happens”(TM). If you want stuff to happen in a “stable” release, take a look at this thing called rawhide. Then re-read this paragraph. If that doesn’t work, ask yourself if you are the best programmer who ever lived? If you really are, and are not going to break something – no matter how insignificantly annoying – and are going to test your non-essential update, have at it. But if my video-out breaks, if my printer stops, if my system doesn’t boot, if the behavior changes, if my proprietary flash plugin that worked just fine yesterday breaks (which does matter), if something isn’t exactly the same after I run an update, you caused a regression, and people are not going to be happy. I expect that only to happen when I choose to upgrade, and you have a choice to leave it the heck alone. Consider that choice as a good first choice and default to it, unless an update is essential.
2). Set a mandate. Either ask the users what you want from them (I have called again for a survey to be conducted), or tell them what that will be (also a valid option). But there needs to be a very clear direction here, and it must be spelled out very strongly in writing. Fedora can’t be all things to all people, that isn’t working, and time and again this is borne out on the mailing lists, and in various other anecdotal evidence. Depending upon who shouts the loudest will result in it either being an everyday Linux distribution for Linux users, or of niche value to those who like to ride the wave on the Fedora development list. Here’s where a series of very specific documents – we might call it a Declaration – comes into being and says “this is what we do”. Period. You don’t like it, fine, but this is the situation. Having something like that also allows it to be shaped and changed. And for users to express their opinions on what should be thrust at them. We’re on Fedora 14. I would have thought we could have gotten a document like that worked out by about, oh, now. How about before F-14 ships?
3). Establish cross-functional workgroups. There is no Desktop, there is no kernel. There is only this kind of use or that. Why don’t we have a “Plumbing” team that handles the low-level guts and meets regularly to sync up on them? We should have various groups that represent more than component IDs in Bugzilla, because the Linux system isn’t quaint any more. The current mechanism of development sees someone introduce some big feature or whatever, break random other stuff, then fix up the fallout, probably slowly and over a few releases (due to the number of people who were not involved early on). Instead, everything should be planned. There should be an actual idea of overall system design, overall architecture, what it is that will happen. Does everything have to have a command line equivalent? Make it a policy. And people are busy. Some are working on Fedora as a hobby, others have different commitments. If you depend solely on who is available “right now”, and who is dropping code today, then you will forever have this mess. Sometimes people are busy on other stuff and you’re going to have to wait a release for your shiny new feature to get integrated, and that’s fine.
4). Set specific goals. Don’t just let people post Feature page ideas randomly. Have a strong process (stronger than now – before anything is allowed to be built and shipped out the door), with an overall vision that those ideas fit into. And have a few people be in charge of overall consistency and vision decide how a feature fits in. If it doesn’t, punt it to the next release. This kind of thing happens to a very limited extent right now. It should be rigorous, it should be tough, getting stuff into the distribution should also be consistent, every single time should use the identical process. If you don’t like that, try Linux From Scratch instead, or Gentoo, or some other roll-your-own effort. But if you want to take on the Red Hat Linux and Fedora lineage, get it right. Make the user experience be the number one priority.
Fedora doesn’t suck, but it could be a lot more useful to a lot more people. And either I am right, or I am wrong. Policy, feedback, goals, all of these things will determine how many of the things I would like to see are feasible, in line with Fedora’s longer term vision, and so forth. So let’s see a very specific vision and direction and all be much happier for it.
Jon.
