Pithy, pithy man.

Once again, Mitch Kapor proves that he’s smarter than I am. In particular, the section “What Open Source Needs to Succeed” is truly eye-opening, and should serve as the playbook for the Fedora Project in general. In particular, it’s what the Fedora Extras Project should strive towards.

Mitch lists the seven bullet points for “what makes an open source project succeed.” Four are technical infrastructure, three are community infrastructure.

So. Let’s look at them, and just for fun, let’s see how Fedora Extras stacks up.

1. Is there a publicly available source code repository? (At long last, yes.)

2. Is there a public bug-tracking system? (Indeed; we’re using bugzilla.redhat.com, and one hopes that our usage will become very conscientious over time.)

3. What are the communication vehicles that the project uses—a mailing list, a wiki, IRC? Do these help people who want to participate? (Yep. We use all three.)

4. Are the tools used in the project suitable for getting the project done? (Ah, good question. These tools are still undergoing serious transmogrification; we’ve got a build system in progress (Sethyoudaman) and an account management system in progress (Sopwithyoudaman), so that’s a start. More importantly, I hope we’re developing the will to create these tools as we discover the need for them.)

5. How does the community work? (In the past, not at all, and this hurdle has been one of the biggest to overcome; figuring out this question is very nearly my full-time job these days. Right now, the community works with an ad-hoc set of processes, documented at fedoraproject.org, with a lot of overhead required of dedicated individuals. To the degree that we can reduce this overhead with tools from (4), we will ultimately succeed, or fail.)

6. How do decisions get made? (This was the entire purpose of creating the Fedora Extras Steering Committee, so that a responsible, accountable decision-making body could exist. There are still open questions about how the composition of this body will change over time, but the key characteristic of this body is that it consists of Red Hatters and community members in equal measure, and all are committed to working towards the right answers for the project as it evolves.)

7. What are the power relationships? (The sixty-four dollar question. One of the central purposes of the Fedora Extras project is to change the balance of power. It’s the first step (among many, I hope) to making the Fedora Project less cathedral and more bazaar.)

I think we’re on the right track. And Mitch, thanks again for your insights. Man, what a smart dude. I stumble for months to get these objectives clear in my mind, and he nails them down in, oh, a page and a half.

Pithy, pithy man.

Small Pieces, Loosely Joined

I like Mitch Kapor so much. Even if M$ did buy Groove. His summary of O’Reilly’s emerging tech conference is short and sweet. Cribbing relentlessly:

* Build with “Small Pieces, Loosely Joined”: (borrowing the David Weinberger book title)
* Design for participation, e.g., have users add value to your data (Amazon user book reviews)
* Make participation the default: Aggregate user data as a side effect. (Flickr’s default for sharing is public)
* Data is the next “Intel Inside”: owning a unique, hard-to-replicate data source as a competitive advantage

/me idly ponders the intersection between this and Fedora… *crackle*

Oh, and also, playing the new Yahoo! Buzz game, which is nifty. Pretend stock market for tech buzzwords. It promises to be great fun. The markets are still a bit underdeveloped at this point; I bought 1000 shares of Fedora, and it went up a dollar. Yeeeeeah, that’s a pretty big float.

Of course, I’m tempted to cheat, and it’s perilously easy: buy up a stock, create bogus accounts to buy that stock up, dump the stock, do it again with another stock. That’s clearly what your leader “gogogo” is doing. But hey — it’s still a cool idea. I do look forward to seeing Yahoo! put together their own version of the SEC, though.

Small Pieces, Loosely Joined

Fedora Project structure

So way back in the day when the Fedora Project was first conceived, the idea was to follow the excellent model as set forth by the Apache Software Foundation: the meritocracy.

Read it over:


From my perspective, I think that you could probably take this document, do a little bit of search-and-replace, a tweak here and a tweak there, and it’s what the Fedora Project ought to look like. The ASF is a proven model. We like it. Tastes great, less filling, all of that.

To wit:

* Apache has the Board of Directors. We have the Fedora Project Steering Committee.

* Apache has Project Management Committees, or PMCs. We have the Fedora Extras Steering Committee, which is pretty much identical to a PMC. There will be other projects rolling down the pike, and their governing structures will look an awful lot like PMCs as well. We’re concentrating on the Extras committee first because it’s where we can get the most immediate traction, and where people can help *right now*.

* Apache has Committers. So do we. In fact, the CLA that one fills out to become a committer for Fedora Extras bears a striking similarity to the CLA that one fills out to become a committer to the Apache project. Committers, because they are doing some of the heaviest lifting, also have a louder voice — but then again, anyone who wants to become a committer, can (assuming they can prove they have the basic skillset required). It’s just a matter of going to fedoraproject.org, reading the docs, filling out a form, and finding someone to sponsor you.

The time will come (and that right soon, I hope) when all of this is True with a capital T, and represented in a glorious document of governance. But until that time, I think it’s important that folks understand the direction and the idea. It’s not about exclusion; it’s about structure and getting things done.

Fedora Project structure