Great post, I agree completely.
On Thu, Jan 27, 2011 at 5:50 AM, Scott Gray <[email protected]>wrote:
> (With so many messages I don't have a good spot to say my short piece so
> here will do)
>
> IMO our problems will only increase with the size of the code base. Every
> time a new feature is committed you have an additional potential audience
> that must be kept happy and our ability to please everybody continues to
> decrease. Unhappy people don't work well together so things just keep
> getting worse.
>
> Solution? Decrease the size of the code base and included features and
> increase the ability for the community to share contributions outside of the
> ASF's repo. Decrease the load on the committers and let the rest of the
> community put their money where their mouth is.
> Some ideas (feasible or not):
> - Pull out all of the themes except one and move each one to google code or
> wherever if there is someone interested in looking after each one.
> - Then do the same for the bulk of the special purpose apps.
> - Separate the framework from the applications.
> - Remove any framework features that aren't used by the applications or are
> of relatively low value and allow them to be dropped in by users when they
> need them.
> - Perhaps even take another look at the possibility of reducing the
> dependencies among the core apps and splitting them (I'd gladly welcome 100
> new committers to the humanres app because I have no interest in it).
> - Turn the payment and shipping gateway implementations into drop in
> components along with any other pieces of code that are suitable for
> extraction
> - Investigate ways to allow plug-in modification of apps and implement
> something (anything) that allows it.
>
> Right now we have a gigantic project with a gateway of ~13 active
> committers (23 total) who have day jobs to worry about along with reviewing
> (and fighting about) commits (or just giving up on this responsibility),
> attempting to improve the project and taking part in these (mostly pointless
> discussions) and then keeping the rest of the community happy. Increasing
> the number of committers just increases the potential for disagreement and
> then stagnation so the only other option to reduce the code.
>
> Give control of features and components to people who care about them and
> then help users find them externally as they need them. Don't like the
> direction a feature/component is taking? Fork it and compete.
>
> Regards
> Scott
>
> On 27/01/2011, at 9:54 PM, Jacopo Cappellato wrote:
>
> > I have noticed some negative trends happening to us in the last (1-2)
> years:
> > * a dramatic decrease of design discussions and an increase in commits
> > * committers are often working for themselves and not for the greater
> good of the project ("if a customer pays me to do something then it will be
> also good for the project")
> > * less peer reviews and mostly focused on formal aspects rather then
> fundamental aspects of the contributions
> > * a decrease in the minimum quality level needed to make a commit
> "acceptable"
> > * a proliferation of "best practices" and "rules" in an attempt to
> improve the quality of the commits
> > * a decay in the attitude and quality of discussions: attacks, critics
> and fights instead of healthy discussions to learn from others and improve
> design decisions
> >
> > Of course I am focusing on bad things, to the good ones (yes, there are
> also good ones) it is easier to adjust: however when the final result of our
> efforts is that a person like David doesn't feel comfortable in contributing
> more then I feel bad.
> > The primary goal of the PMC, and the community in general, should be that
> of creating the perfect environment to facilitate contributions from people
> like David, and limit/review/improve the contributions from other less
> blessed contributors: it seems like all our efforts are obtaining the exact
> opposite result.
> >
> > Jacopo
> >
>
