On Thu, May 06, 2010 at 03:07:51PM -0700, Jesse Keating wrote: > On Thu, 2010-05-06 at 16:18 -0500, Mike McGrath wrote: > > I joined the board on the platform that I wanted to bring focus to the > > project. I felt and still feel that our lack of a unified vision has > > caused anyone and everyone to join the project. Now that they're here and > > have conflicting views on what Fedora should be, we're seeing lots more > > in-fighting because of it. > > > > In pushing for this unified vision I think I've accomplished just the > > opposite. The more we as a project thought about the whole "what is > > fedora" "Who is it for", the more divisive a subject it became. Everyone > > thought their version of Fedora was the right one. We went in the > > opposing direction of unity. > > > > We've seen the project continue to grow but scale poorly. Our packagers > > used to be able to do anything they wanted, now have to follow a process. > > People don't like being told what to do, regardless of if its better for > > the whole or not. Our processes have gotten more complex and difficult to > > follow, especially for causal packagers while some needed processes still > > don't exist. > > To add to this, it seems to me that we as a project and as project > leaders are too afraid of turning away those that joined under the > 'anything goes' time, or rather the time without direction. When trying > to decide on a direction and goal and vision, we seem just too unwilling > to tell people that what you wanted out of the project just isn't what > we want, and just isn't where we're going. We're too afraid to turn > people away. > > People say that Linux is about choice, and that Fedora should be about > choice and anybody should be able to do anything they want with Fedora. > I pretty strongly oppose this view point. To paraphrase Adam Jackson a > bit here, Linux is absolutely about choice. You can choose to build > your own distro, or to use and participate in one of the existing ones. > Fedora does not and should not be about that level of choice. Fedora is > but one choice in the vast sea of options. And if you don't like them, > but like some of Fedora, we make it very easy for you to take Fedora and > make your own thing out of it, outside of the project. I strongly feel > that in order for Fedora as a project and community to continue to > scale, we need some hard direction and real ability to say no, and to > put certain goals above all else. We may lose some people, and that's > OK, there will be somewhere else for them. What we will gain is shared > vision, a common goal, and much less infighting about the little things. > > When we continue to try to be all things to every person, we continue to > deliver poorly and disappoint everyone nearly equally. I don't want to confuse "doing not much better than anyone else" with "delivering poorly." But that's no excuse for failing to set a higher bar than we've been doing. The current state of Fedora is that most of our operations enable us to be an RPM-based Debian, as Seth said in his blog[1] recently. We do release more quickly, and the releases are relevant due to heavy development resources and being the upstream for RHEL, the most important Linux distro to the world at large. One could argue that as long as Red Hat can build their product from Fedora, vital resources will keep flowing into Fedora. But it seems to me that if we're not producing something that captures the imagination of a large audience in a growing market, the relevance of Fedora could easily diminish. We know the Fedora download is the most prominent way the Fedora Project advertises its work. People view and investigate what we've made, discover how it's made, and then get interested in participating in that process. While I would argue that none of the statistics Mike brought up are great from a scientific basis, there's not an undeniably huge uptick in the number of Fedora downloads, and that *is* a concern. It's only one measure of our appeal, but it's an important one. And as one of the people who makes the case for resources for Fedora to Red Hat managers, I'd like to be able to show much higher metrics when I propose increased investments. Lest anyone think that's a very selfish and unimportant motive, I'd say that the majority of people who spend their time on Fedora, no matter whether they're paid to do it or not, care too. They'd have increased satisfaction by knowing their work reaches an even faster increasing number of people. There may be some to whom this measure is completely irrelevant, but they should at least not be *distressed* by an increase. At the same time, though, we don't have good ways to find out how well we're doing at growing the community. Paying attention to mailing lists isn't sufficient since a lot of work goes on outside lists. And lists are exceptionally poor barometers when they're dominated, and our perceptions skewed, by a few toxic personalities. Account numbers don't tell the tale either. We need better objective metrics that will help us assess how contribution is happening, and how well it's growing over time. This is an important discussion for us to have openly in our community, and also an example of the transparency we enjoy as opposed to some of our perceived competitors. Establishing focus for our distro *doesn't* have to mean shutting down a slew of things the community wants to work on. But we need clearly established priorities, and a common understanding of them across the whole project. Mike's comments about growing while not scaling make a lot of sense in this respect. Increasingly clear priorities and criteria for releases, testing, and critical path are a good example. Over the last few releases we're relying on well-documented and objective measures to determine release readiness. With a clearer set of priorities and end goals, we can realize a higher level of collaboration and coherence. To make those kinds of decisions is not a step to be taken lightly, but it must be done definitively. Leaders throughout Fedora, not just the FPL and the Board, would have to agree we'd travel this road for the next three or four releases, and collaborate together to execute against it. Some teams, like the Fedora marketing team, have already said they are eagerly looking for this sort of priority framework to help them actively assign work. Others, like Fedora's translation teams, might not be affected as much. This isn't something I think we can do by dipping our collective toe in the water for a single release. We'll also continue to ensure the work of the Fedora team in Red Hat, who are paid to work on Fedora full-time, is well aligned with these priorities as well. For instance, one way we could capture important community metrics would be to centralize the capture of contributor work such as project commits, package builds, wiki edits, and so on. That would give us a basis to know how our strategies and implementations affect our contributors' efforts. Work has already started on a Fedora messaging bus that would allow us to provide better automation and communication for contributor work. That bus would also provide a way for us to capture the statistics we need to more effectively measure community work and see how it changes over one or more releases. A joint responsibility of the Fedora Project Leader and the Fedora Engineering Manager is to work together closely to support project priorities in this fashion. We shouldn't be stringing along or cajoling people to remain in the project. A healthy community should include some attrition. We also need to effectively raise the signal-to-noise ratio in our communications channels to achieve our goals. At the same time, we need to be very careful not to stifle constructive criticism and debate, which are part of the lifeblood of open source. This is one of the most difficult balances to strike in any community, and perhaps that's why even authoritative works like The Open Source Way[2] don't address it well yet[3],[4]. While Fedora shouldn't become a monoculture, without deciding when some issues are closed for the time being, we waste a lot of time on non-constructive and unprofitable discussions. I'd propose that we as a community can make such a list on the wiki, and that list can be used to identify when we have problems occurring on our mailing lists. This email is already too long to launch into a set of project priorities, but I would like people to read and think about this email before moving into that discussion. * * * [1] http://skvidal.wordpress.com/2010/05/07/dissidents/ [2] http://www.theopensourceway.org/ [3] http://www.theopensourceway.org/wiki/Stuff_everyone_knows_and_forgets_anyway#Do_not_let_poisonous_people_bog_down_the_community [4] http://www.theopensourceway.org/wiki/Stuff_everyone_knows_and_forgets_anyway#Disable_poisonous_communication -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com _______________________________________________ advisory-board mailing list advisory-board@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/advisory-board
