There's not a lot in GP that would be of general use, though the idea is to make a tarball available at some point.  A raw dump.

We will actively be factoring pieces back into the mainstream, though.  In fact you can see it already in the completion of "ad_form" and its documentation (I plan to put together a more complete doc with examples in a few weeks).

The internationalization stuff wants to filter back, too, but needs to be generalized as it's currently tied specifically to GP's site structure.  But it's going to take work by someone who understands that code and understands the OpenACS 4 core - I'm assuming I'll do it later this fall.

But a dump for site code might be interesting, a place where you could weed through code written by others looking for things to borrow for a current project.

The only possible problem I could see would be if there's some great imbalance between those companies that contribute (helping all speed implementation and lowering costs for clients making everyone more competitive) and those companies that don't.  I don't see that being a  problem with the current set of companies in our community.

Please let me know about your ideas on how such a dump for site code should look like.

• a description of what the code is doing
• a checklist of current OpenACS packages touched by this code
• Link to see the code in action
• Version of ACS the code was derived from (so we could do a CVS diff and check out the difference, to see how much work it would be).
• Maybe a field describing what is liked most about the code.
• A convenient way to browse the code
• A page reminding people not to upload a whole site (but digestable pieces)

It seems to me that a link to the site that used the code and the author of the code (so proper attribution can be given) are enough overhead. A semi-sensible organization of the code (by site that used the code) should be enough, too. So if I want to see the implementation of a neat feature in greenpeace.org, for example, I look at the greenpeace.org subdirectory in the code dump and find a bunch of tar balls that Don uploaded. Fine, I'll download the tar balls and look at the code in my own sweet time, and I'll try to figure out the portion of the code that implemented the feature myself. No need to bother Don to describe what the tarballs are for, or separate the tar balls into "digestible" pieces, because he may not have the time.

though it is an interesting approach, I'm against it for the following reasons:

• If we use a core dump, this guarantees (in a way) that only people from the community would look at the code. I mean, we can even register who downloaded the code. Therefore you can assume that the chance of getting something out of your code which is returned to the toolkit is higher.
• IMHO it is easier to convince clients that they should give the code back to the community of OpenACS instead of all the people around the world, who just happen to come to your page.
• I try to imagine Greenpeace doing this. Within a month they will probably have 200 bids for improving their website from random strikers all around the world trying to get their hands on some money.
That said, if we get this as a package, yeah why not. Just because I wouldn't do it does not mean everyone should be opposed to it and it is always better to have the choice. If you have a strong feeling about it, you might as well make a community bid. After all, it is not that much work .

So I doubt in practice there'd be a significant effect.

Anyway ... turned off by default?  Maybe a link on the default index page for the site if turned on.  Why not?  The default index page never survives customization anyway ... so our OpenACS community members could access via the "secret" URL (just as I do here to reach the site membership page at http://openacs.org/directory, not really a "secret", just not linked from anywhere and I keep forgetting to add it).