I think this is a great discussion to have, but I think it would help if there were specific examples you could share so that we all have a better understanding. For example, I think I'm guilty of this in some respects, but I'm not sure if this is what you're talking about. Let me post one of my examples and the workflow that has been followed (correct or otherwise):
1. We have a need for CloudStack to do X 2. We determine if it's a feature that makes sense for CloudStack in general to have, or just us (e.g. it may be some small custom thing that talks to our internal resources or storage). 3. If it's generic enough that it makes sense for upstream CloudStack (and believe me anything we can push back we want to), we post to the list to see if anyone else is working on it or interested in it. 4. We get feedback, but whether or not the community is interested in it, we're going to develop it. 5. If it seems the community is interested in the feature, we post our patches for review. Small fixes to existing things are simply committed, but new features need review. Even if the community didn't respond, we post it for others to look at in an attempt to get it upstream. 6. If there's sufficient feedback the change is committed, otherwise it's abandoned. The key here is that we're leveraging CloudStack, but we can't be beholden to what the community deems are good features, so we can (and should be able to) develop things independently. Then we say to the community "here's this patch we've developed that implements feature X, if you're interested", which we may have attempted to start a discussion about previously, with mixed results. Obviously we in particular haven't had more than 2 or 3 things total, so don't read too much into my example, but I could see how it could become a huge problem. So if we have a procedure that can mitigate the two forces of "collaborating on all features" vs "developing features that are necessary and feeding them back to the community if they want them", it would help me, in particular, to plan our workflow better. On Fri, Dec 14, 2012 at 1:12 PM, Chip Childers <[email protected]>wrote: > is email on a positive note, let me say that I > personally want nothing but the best for Apache CloudStack, both as a > software project and as a growing community of like minded > individuals. Our young Apache community has done some great things > together so far. Please do your part to help us continue to grow and > evolve in the spirit of an Apache project. >
