couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: Apache sub-projects
Date Fri, 14 Aug 2009 18:34:02 GMT
On Fri, Aug 14, 2009 at 10:19 AM, Noah Slater<> wrote:
> On Fri, Aug 14, 2009 at 09:55:34AM -0700, Chris Anderson wrote:
>> I generally agree with those principles, although I think we can get
>> away with being informal about them at least at first.
> Creating a project as a sub-project of Apache CouchDB is a necessarily formal
> affair, and on that we can't easily go back on without a lot of pain. Blessing
> something as a sub-project will have massive implications for the community
> around it, and around CouchDB proper.
> While I think there is some obvious value to be found here, like with Django, I
> think that we need to think about this seriously before we accept any projects.
> If if we decide on a criteria for inclusion at some future point, that excludes
> some existing sub-projects because we were in a rush to add them, then we are
> going to have a bit of an awkward problem on our hands.
> Does the ASF have any guidelines for this?
> Is there any ASF lore that we can fall back on for guidance here?

I think a shared understanding of our values around subprojects (and
more generally) is important. But I'd be quite happy to bring in
sub-projects on an ad-hoc basis.

So often it is a mix of the people, the code, and circumstance that
makes one project stand out for inclusion. Trying to apply the same
reasoning when bringing in all/any sub-projects doesn't seem
necessarily productive. I *do* agree with you that we should talk
about how to make the decision to bring on a sub-project. I just think
that we should treat them on a project by project basis.

I liked the Django quotes you posted. I'm pasting them again here:


I think that we have a lot to learn from Django about selection here:

Just to summarise in quotes:

 "contrib packages should be removable."

 "anything in contrib needs to be generally accepted as the Right Way to do
 something for a large majority of users."

 "contrib packages should solve problems encountered frequently by real-world
 web developers."

 "Good contrib packages tackle issues that that are not trivial, are bikeshed
 prone, and are difficult to get right for the common case. We want to prevent
 folks from needing to decide among seventeen different session frameworks, for

 "there’s a danger in bringing something into the core: it stifles future
 innovation. As soon as we “bless” a contrib package, we drastically reduce
 impetus to write competing libraries. So, a good contrib package should have
 general consensus, and should be fairly mature."

Would we need to adopt the same thinking?

> --
> Noah Slater,

One thing all the projects we've mentioned have in common is a
polyglot of languages. I think it will be healthy for CouchDB to have
a few languages represented in the distribution.

Now that I think about it, QueryServers might make a good sub-project.
It would be a good way to involve people from the Erlang / Ruby /
Python, etc communities to contribute to CouchDB. Now that we have a
test suite for query servers we can afford to keep contrib versions of
them in more than one or two languages. I'm not proposing we refactor
this out immediately, but it's the direction I can see sub-projects

I'd love to hear what other people think about sub-projects in
general, or if there are other projects we haven't mentioned that
would make good sub-projects. It would be helpful to have some obvious
"that's not a subproject" candidates as well.


Chris Anderson

View raw message