On 5/30/07, Craig McClanahan <[EMAIL PROTECTED]> wrote:
On 5/30/07, Henri Yandell <[EMAIL PROTECTED]> wrote:
> On 5/30/07, Ted Husted <[EMAIL PROTECTED]> wrote:
> > On 5/26/07, Henri Yandell <[EMAIL PROTECTED]> wrote:
> > > Ack in terms of driving a community away because it is unable to meet
> > > our arbitrary criteria.
> >
> > That sort of thinking just seems so Borg to me. It's another way of
> > saying that a software product only has value if its hosted by the
> > ASF.
> >
> > If a subproject, or even a project, is down to one or two committers,
> > and those committers can't find a third, and don't want to apply to
> > the Commons or declare the product dormant, then setting up shop on
> > GoogleCode is an excellent alternative. I've done the same myself, and
> > it's not the least bit painful. In many ways, it's joyful.
>
> Which Apache projects have you moved to GoogleCode and found it a
> joyful experience? ie) I presume you mean starting a project there
> rather than moving a community from the ASF.
>
I suspect you are missing the point that *I* at least think Ted is
making ... doing open source outside of Apache is fun, if you like
doing open source. Doing open source inside Apache is a pain ... even
if you like doing open source, and even if you are an insider and know
all the loopholes.
> My distaste for driving people to an open source repository is not
> because of the repositories, but because our rules have driven them
> out.
>
> > It might even be healthy if more ASF committers were involved with
> > other hosts. The ASF may be a cult, but it should not also be a fetish
> > :)
>
> Other communities, not 'host's. ie) You won't learn much from
> code.google, java.net or sf.net other than whether you love or hate
> the infrastructure. I bet a lot of us are involved with other
> communities.
>
You're right that it's more community oriented than host oriented
(because it is about the process, not the technology). You are wrong
if you believe that "the Apache Way" (if there is such a singular
thing, which I would dispute based on seven years of evidence to the
contrary) makes things easier rather than harder. Yes, there are some
benefits of the "Apache" brand, but it is an open question whether
they are worth the costs.
For myself, I have lots of ideas to do future open source projects,
and (at the moment) zero plans to do them here at Apache. The
emotional and procedural and cultural costs are too high to compensate
for the branding benefits.
Been there (ie: pissed off), done that (ie: grumbled). It's not the
black and white scenario it seems at first. I'm still trying to decide
what it all means to me though, sometimes moving back to the UK near
my parents and finding a nice dull job pushing numbers is so very very
attractive. Brain dump of current thoughts follows...serves you right
:)
---
A bunch of coders took a project written by others, forked it, hacked
around with it and had a lot of success - based primarily on it being
the right time and secondarily on having created a positive atmosphere
to development. They created a foundation to support this development
- its goal to enforce the atmosphere that the first project naturally
evolved to.
A bit later, as the foundation grew beyond their original development,
they didn't like the different cultures that inhabited the foundation
and, effectively, the Apache Way was created to impose a monoculture.
This is imposed by a relatively vague set of memes that are strongly
applied by many members of the community. The preaching of this way
also happily created a set of memes to resist the monoculture advance;
bureaucracy, hypocrisy, arrogance.
---
Definition for the below: "Enterprise Open Source" - the massing of
open source projects into a larger group. Sorry that that phrase
clashes with existing ones, I haven't got a better term yet. Might
just have to be 'Enterprise Foundation'. So - Enterprise meaning
'large collection of smaller entities'.
---
The strongest anti-meme is the anger against enforcement. This is the
primary difference between Codehaus and Apache for example, where
Apache enforces, Codehaus merely recommends. Once you sit down and
identify many of the Apache memes, I don't think open source
committers would be against them. Open source leaders might.
Remember... the ideas in the Apache Way are not reality, they are
unreachable targets.
Idea -> Individuals. Companies don't get to use their bulk to bully
individuals out of the conversation. Employers don't get to strongarm
their employees.
I think we get relatively near the ideal here. I get to walk in to an
interview and when the obligatory Prior Inventions agreement shows up,
I can pull out the CLA and CCLA and get some level of protection. This
is where the enterprise bit helps Apache; employers are going to laugh
when you pull out MyPetProject's CLA. They'll listen if you are
talking about a JBoss, MySQL, Spring or Apache CLA.
Idea -> (Re)leveling playing field. Starting a project doesn't
designate you as forever worthy. You have to be active to remain as
the 'Project Leader'.
We suck at this one. The meme is "There is no such thing as a project
leader", which is bull. There totally are project leaders, but they're
there on merit deigned them by the project community; and I'm sure you
can outlive your merit for a while before an explosion or someone
notices you're absent. Again, a MyPetProject is trickier here. Either
I'm the apparent leader for life and I'm wondering how to reassure
others that I'm not; or I'm wondering whether I trust the current
leader enough to get/stay involved.
Idea -> Legal issues are paid attention to, aka your ass is covered
(somewhat). There are open source projects who distribute non-open
source dependencies without telling you, or whose code could contain
IP they've not vetted etc.
We are on a score-draw on this one. The Apache Way does do well in
terms of enforcing attention, but it's never going to be a replacement
for a user doing their own due diligence and we go over the top and
create bureaucracy. We go over the top because when faced with a legal
issue, only a lawyer is going to consider another option other than
'play it safe'. Plus as things change, it takes forever for people to
discover that things are different and arguments are repeated again
and again (cf: the JCS vote thread). I think the members were
partially intended to help with this spread of information across the
foundation, but I don't think it's working. In fact as they're more
often sure of their knowledge, they're much less likely to read new
documentation (if and when it's written).
[Need to think of more here...]
---
One idea that I think we've failed to find is 'trust'. If some
stranger shows up at MyPetProject, the amount of effort I put them to
making to earn my trust should be less than the amount of effort I put
someone I know to. The Apache concept of having 'done one good thing
and being let in the door' _should_ mean that we make it easier to
give them commit access to our Apache project. We do do that
sometimes, but it's not something we talk about. And it's not far
enough. It should be at the point of "Hey, I want to hack on X";
"Okay, here's the karma". That's something that's worthy of a meme.
---
Benefits of Apache. The easy ones to list are 'brand' and 'TCKs!'.
Then there's a kind of vague one about "companies like Apache stuff"
which is part of the meaning of the brand to people. Either the brand
means Webserver to them and they listen because its the only name they
recognize, or they're aware of the extreme memes of the Apache Way and
they like what they hear (enforcing rules on open source probably
sounds pretty cool to enterprise corporations I think). Admittedly the
more likely answer is that they've never heard of the name anyway.
There are other benefits of the foundation approach.
Good shared infrastructure. The code repositories are good for free,
but they suck for anyone who's got a server and a bit of time to set
things up. Shell account, responsive svn, jira; all of these are
better than the experience I've had at sf and code.google. I've not
used java.net, mostly I just sit and swear at how often they make me
log in for what should be public information.
The trust network I mention above. And the larger network of people
who are moving passed. A tiny corner somewhere with MyPetProject tends
not to get many passers by. This is often a common anti-meme, that it
is somehow unfair that the project at Apache gets more noise and
interest than the one out there on its own; but it's like setting up
shop on a major road or a minor road. The major road is quite simply
more travelled.
The protection of being a part of something much bigger. The chief one
here to my view, which I've mentioned already, is the extra strength
it gives you in your relationship with your employers. I don't know
how well that works for huge employers - employees there can't really
use my line from a few years back of "Hey, the big companies are happy
with their employees committing" :) There's a negative here, something
bigger is a bigger target. Maybe someday we'll all regret the lack of
agility.
---
MyPetProject. It's fun stuff. My current MyPetProject have been a
bunch of JIRA plugins. Because I'm not going to pull off MyPetProject
CLA, they're squarely owned by my employers. They're AL 2.0 though, so
I (or someone else) can fork them anytime. I've not had any mailing
lists, or online svn, I just push out jars and src zips on a website.
People talk to me directly, or they post comments on the Confluence
pages at Atlassian. It's not a good way to build a community, but it's
been enough for my fun.
Once I find a dedicated box to stick things on, I'll setup JIRA, Jive,
Fisheye etc. There's a direct benefit of MyPetProject - I don't have
to deal with hours of crap to get Jive and Fisheye up. And I get to
customize my JIRA heavily without arguing with the rest of you.
Releases. Releases are wonderful. I can release with barely a thought
- and it's not through any Maven magic, I still do it all by hand.
However I don't have to ask anyone for permission. Release? Yes. Okay.
Done. Bugfixes can be back in a JIRA admins hands the evening of their
bug report.
---
Time for family. Suffice to say - definitely a subject I've been
thinking a lot about the last few years. Wtf is Apache, why tf am I
here and how much beer will commons.codehaus.org take ;)
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]