Hey Don, Thanks for your reply. You are quite right, of course. I hope I am also right at the same time :-). Maybe I can clarify...
On Mon, Jan 16, 2012 at 4:48 PM, Donald Whytock <dwhyt...@gmail.com> wrote: > Like Apache, But Sexier...LABS? I can totally see that. Anyone want > to start an Apache LABS podling? I am assuming you know but I will nevertheless redundantly point out for those that don't that there is actually a http://labs.apache.org/ . It is pretty cool and has a relatively sexy web site :) > But while community can be flexible in a lot of ways, policy generally > can't be. The rules are there; exceptions can be made, but in terms > of law it's generally safer to assume they won't be. So, as much as I > hate to say it, I don't think "community over policy" can actually > work. Indeed, some of the rules apache has are rules that it has to have because of the law. Some others come from its tax status -- apache could ignore those rules, but then it would lose a financially beneficial tax status. Others rules apache has written down in its bylaws [1], and the apache members could jump through a bunch of hoops to change some of those. But, then, a lot of the rules that apache has are there because apache wants to have them. I will write you out an example. Once upon a time the incubator had said that incubating projects should not do binary releases, for a couple of reasons: * to avoid users downloading incubating software: apache was concerned that end users would not understand the tentative status of incubating projects; * to give projects yet another incentive to do their incubation process quickly: incubation should be as short as possible. Back then I think we thought 3-6 months would be the norm; * legal umbrella: apache the Foundation appoints Officers who have Committees who make Decisions on behalf of the Foundation. Releasing software is such a Decision and it's reserved for PMCs. Podlings don't have PMCs so who should release? But then along came a project that really wanted to release early, release often, and also do binary releases [2]. Their mentor had actually encouraged this since he believed "release early, release often" is good engineering and community-building practice. So what to do? Well, the issue was discussed, at some length, and it was decided that perhaps we could have releases if we added a disclaimer, and that the incubator PMC would vote and assume responsibility for the release. The project added the disclaimer to its website and made its release. Everything seemed fine, so someone turned those words into a template [3] and stuck them on the policy website along with a description of how to do a release. That was in September 2003 [4], and it's been policy since [5]. If for some reason you find these disclaimers really really horrible, you can go back into the commit history for the policy docs, and then into the e-mail archives to figure out why the policy says what it says, think about it some more, and perhaps come up with a better idea. Then that idea can be discussed and the policy can be changed, by the community :-) I personally think this is *fascinating* history. I'm weird like that. Unfortunately in 2012 those words from 2003 seem to have significantly gained in weight. A lot of projects have followed the rule without complaining, so why should you? This is not just some words some guy wrote, it's a community decision with a rule on a pretty website (not on a rebel CSS-less wiki with an "edit this page" invitation), and it has the word policy slapped on top of it. These days we probably have mentors that had never thought about open source communities, when the incubator had those rules already on the website. They've seen that rule, and they hand the rule to their podlings, who then follow the rule. The feeling is very different and the dynamic is different: it has changed from "hmm, how should we tackle this" into "do what the rules say". This isn't bad per se (it's a good rule, probably), but I believe we do need to spend effort to compensate for the lack of positive feeling. Hence, community over (but not against) policy! cheerio, Leo [1] http://www.apache.org/foundation/bylaws.html [2] http://mail-archives.apache.org/mod_mbox/incubator-general/200309.mbox/%3c4c2f1577f2ef2840a9ae9ec61860c8810a0...@usseex01.amer.bea.com%3E [3] I tried to find the first version of the wiki page, but that was hosted on a machine owned by sun and inside a sun data centre, and we didn't migrate all the history (sort of in violation of apache infrastructure rules even then, but hey, projects really really wanted wikis and there was no apache hosted wiki...oh man, those dare-devil incubator rebels, breaking the rules!) [4] http://mail-archives.apache.org/mod_mbox/incubator-general/200310.mbox/%3c4c2f1577f2ef2840a9ae9ec61860c8810a1...@usseex01.amer.bea.com%3E [5] http://incubator.apache.org/guides/branding.html --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
