Also, I will be the last one to suggest that a client project necessarily be made totally open just because it's been promised to be released. That screws with deadlines, contractual responsibilities, client expectations, etc. Neither am I suggesting that all development be made totally available, nor should it go on in the bboards only.
But we do need to realize that way too much is going on in the back rooms. There are some consistent and core people, but there are a great many lurkers out there as well. Transparency is not only nice for the core developers to be able to watch as things develop but also provides an in for lurkers either to participate or to test new pieces out.
Allow me to provide an example for how this kind of transparent development can take place without compromising development efficiency from my experience. Dave Bauer and Jun Yamog have taken a great deal of interest in using ETP for their own projects. They contacted Luke Pond with a lot of their fixes, suggestions and questions. As the three of them have poured over the code, decided on improvements and culled a feature set, they've decided to build ETP2.
Before beginning development, Luke wrote up a preliminary design document and posted it on the boards to solicit feedback. If anyone is interested in adding to the list or in helping to develop the package they are free to ask or post suggestions.
In the meantime, Luke, Dave and Jun are working out of a private CVS on Musea's server that was set up for expediency's stake. Once there is an alpha or something it will be merged back into the main CVS. If it were possible to set up a private CVS for small development teams on the OACS box, it would have been there.
IMHO, I think this might satisfy everyone's desire for greater transparency while not limiting anyone's personal work preferences.
As far as dotLRN, Ben, no one is questioning your leadership or your right, along with Sloan, to choose the direction of dotLRN. You've got a lot more invested in its success than anyone else. I want to make it very clear that I and the community recognizes that and does not question it. Particularly since you must deliver a rather focused scope to your client.
Some are only asking that in the future when an opportunity arises like the portal package that you consider strongly to solicit community input before pushing ahead on its development. I think that this will not only benefit your development process and schedule with increased design feedback but will strengthen your position as benevolent leader.
And this should apply to EVERYONE that is building new packages for OACS, just as a courtesy to the rest of the community and in the interest of building a better OACS.