It is very useful to be able to do checkouts (anonymous is fine)
to see what was done on a project. The truth is, people working on
projects don't always have time to do this sort of thing and if you
can enable others to do it then there is a higher probability that
fixes will get pulled in.
It is also quite useful for other people to see what has to be changed on
a deployed site and for places that can operate in the public eye
the visibility is a great thing. Greenpeace has an open management
site and it makes for interesting reading. One advantage
aD had was that with a lot of client projects going on you got a
feel for what people had to change in the toolkit and that provided some direction on development that might otherwise have been absent.
I hope that as more openacs sites are deployed we will see some
sites managed "in public" like greenpeace, more people writing up
what they had to do to build their site, and of course
people feeding the work they have done back to the OpenACS (or enabling others to do by providing access to source code).
In looking at what was in the greenpeace bugzilla and the code they
wrote I can see several things we should do that would make
deploying most sites easier. As we aggregate such lists from other
sites we can define a consensus about where to go based on real world
experience which to my mind is the ideal way to advance OpenACS.