Hi all, I'm writing this email with my PPMC member hat on, but not speaking *for* the PPMC.
This is a bit long, but needs to be shared. Please do take time the time to read it. Recently, some of us have been struggling with how to help guide the community toward better collaboration on this list. We are specifically concerned about how feature decisions and development is occurring, and that in some cases it's not happening within the community. We're seeing the problem in varying levels of severity, ranging from slightly less than great collaboration, to near silence until a feature is submitted. The other pattern that's visible is the approach of providing updates to the list periodically, but not active collaboration on list and with the community. Of particular concern is when this is being done by committers on the project, although all contributors need to remember that we are working to build a sustainable and open community here. You are all part of the Apache CloudStack community as individuals. Certainly, many of us are working for a $dayjob that may pay for all or some of our time on this project. However, on the list and in the community, your $dayjob does not dictate your work here. Organizations have no standing at Apache, only you as individuals. Features that may be an organizational priority for your $dayjob should still be completely handled on the list. This includes everything from the initial concept discussion, collaboration on the design, coordination between developers, test engineering, and finally getting into a CloudStack release. This also extends to aspects of our project that are not directly tied to building new features. When we kick off a testing process of a release, I'd like to see someone offer their time to act as a QA lead for a release cycle, and for the community members that want to be part of that testing process to individually volunteer for the work. When we do marketing for the community, the same rule should apply. Individuals that act as product managers within their $dayjob role, and who's product may rely on this community in some way or another, need to understand that their collaborative contributions are just as important (and very much wanted!). It really boils down to a simple rule, and one that's consistent across Apache projects: Things that are not done in the project community are not actually community actions. For example, this means that feature development that isn't fully executed in the open and through the community process are subject to the IP clearance and / or the Software Grant Agreement contractual process, assuming that the *community* agrees to include the work in the project's codebase. These are fairly onerous processes, so I hope that we don't have to use them frequently. Now that's the policy perspective, but there's a community development perspective as well (which I personally feel is even more important). Each time something is done by organization X, and not done by individuals working within the community, the value of the community is lessened. As of right now, I'm personally going to be watching for areas where a veto must be thrown on any action that isn't done with the community in mind. I know that there are others that are going to be looking at doing the same. This isn't something that we want to do, but it's necessary to our long term health as a project. FWIW, here are two good pages on *why* this is such a community development concern: http://producingoss.com/en/setting-tone.html#avoid-private-discussions http://www.theopensourceway.org/book/The_Open_Source_Way-Stuff_everyone_knows_and_forgets_anyway-Take_extra_extra_extra_care_to_have_all_discussions_in_the_open.html Trying to end this 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. -chip
