cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Revelle <>
Subject Re: working together
Date Tue, 07 Apr 2009 20:58:33 GMT
Please take what I say with a grain of salt as I'm not invested in  
this project, but I have been watching it since the initial open  
release by Facebook.

Comments inline.

On Apr 7, 2009, at 4:10 PM, Torsten Curdt wrote:

> Hey folks,
> I thought back and forth about whether this email should go to the
> private list or not. But I have a Cocoon background and in Cocoon land
> we found it useful to only use the private list when there is really
> no other way. This is about the community so I think it deserves to be
> discussed in the open. I hope no one is offended by that approach.
> Let me try to explain how I see the history of Cassandra. Please
> correct me where I am wrong:
> Cassandra was (mainly?) developed by Facebook and is being used in
> production over there. At some stage it got open sourced on Google
> Code. External contributors did not feel like there is a real
> community around it as patches did not get applied. Out of frustration
> people started (or at least proposed) to fork the code base. As a fork
> means community fragmentation the projects has turned to the Apache
> Incubator hoping to turn this fragmented contributors into a healthy
> community.
> In January the project got accepted. Papers were filed and in March we
> saw the code enter the Apache subversion repository. A few weeks later
> a first committer was proposed. Unfortunately no one noticed that the
> actual authors bringing the code were NOT on the private list where
> the vote was held. So we got a new committer without the consent
> and/or feedback of the original authors. A big surprise. The people
> that brought over the code now feel a bit betrayed by the process.
> They have to deal with a committer that does changes all over the
> place on a code base they depend on for production. They have the
> feeling these changes are untested (at least not tested enough to get
> right into production at Facebook) and that this destabilize the code
> base. On the other hand there is new blood, new drive to the project.
> While Facebook needs it's stability, other contributors needs the
> change to meet their goals and deadlines.
> So the problems I am seeing are:
> 1. We elected a committer without real community consensus. The
> barrier of entry was unnatural low on this one. On the other hand we
> need non-FB committers for the graduation. The more the better. (No
> reason for low entry barrier though!)

Jonathan Ellis has been working on various Cassandra code bases  
released by Facebook for at least nine months now,
his Cassandra repository on github had become the community standard.   
He's one of three people in the world that are qualified to be a  

The recent issues have to do with Facebook developers having  
expectations that differ from open source standard practices.

> 2. A missing definition of development process:
> - What is considered a valid code review?
> - How much are changes discussed up-front?
> - What is the roadmap? ...for whom? (weighted as a community)

All important items, due to a lack of leadership this hasn't been  

> 3. Is trunk considered "stable"? Or aren't we missing a stable branch
> for the required stability? Once we have the separation between stable
> and trunk: Will patches really find it's way from trunk into stable?
> Is Facebook OK with that approach. Will everyone cope with the
> additional work of merging? Would it be useful ...or overkill to use
> merge tracking?

No, the trunk should build and pass tests, but recent changes to a  
should never be considered "stable".  The definition of "stable" even  
indicates that.

> 4. Real world testing feedback is not publicly available. So the
> feedback on changes will only slowly reach the community. This is not
> easy for a project like this. But is there a faster way to provide
> testing feedback? (IIRC Yahoo was providing testing feedback for
> Hadoop. They even try to auto-apply patches from JIRA)
> 5. Is there really no code ownership issue. Working on a code base for
> 1-2 years can get you attached to the code you have written. Can
> everyone really let go? Is it OK if someone else really just rewrites
> parts of what you wrote? (No, it doesn't mean the original code was
> bad! But maybe with the new code it is more readable ...
> understandable - especially for someone who hasn't spent the past
> years working on that code) Is there room for refactoring?
> Anything else I am missing?
> This is a tough situation but I hope everyone sees this as an
> opportunity. Please let's discuss this openly in civilize manner.
> Focusing on how to solve these points rather than looking at the past.
> Please talk to each other. Can you/we work this out together?

Lack of leadership is the most obvious difference between this project  
and healthy open source projects.

I hope that changes.


> cheers
> --
> Torsten

View raw message