My view is that generally for features we add they need to be
used by a bunch of people before the rough edges get smoothed
off. A good example was the upgrade of openacs.org from
3.2.5 to 4.6; just after we did that we got a tremendous
amount of feedback about little easy things to fix and we
fixed them because we use them all the time. It was the biggest boost to usability in forums and other packages
heavily used on openacs.org that we have had to date.
having openacs.org as a testbed for new features provides two
things I think are important, one is immediate feedback from
the community, and the other is visibility. People see what we are trying out and if something does not work out it fails fast.
Another issue is resources. We really need to make rolling things in to openacs.org and back to the release branch easy. And while I appreciate the sentiment that
we should run openacs.org's cvs archive the way we recommend
people run a prod site, the downside is merging changes back from openacs.org would be much harder and given the track
record so far I doubt it will happen unless it gets easier. The only reason we recommend people run their own cvs archive for their production site
is that the better alternative of having a branch in the
main openacs.org repository is just not an option for any other site.
