Forum OpenACS Q&A: Getting the source out of sites
companies posession that they can't release because they are
overwhelmed by the amount of work they need to do, wouldn't it be a
good thing to let members of the community, who have more spare time
at their hands, do the grunt work of releasing the code site independend ?
www.canaan.com, www.sterlingpr.com, www.infiniteinfo.com, www.numeritech.com, www.e-sulat.com.ph, www.semizone.com, www.videoauthority.com, xnet1.infiniteinfo.com
I am not sure if we can give all the site codes because there are some specific info on it about the client. But I think giving parts of the code is ok. I know this is GPL but when deadlines comes sometimes you have to make it work. So I guess this is one of the main problems why code is not given back. The code is not good for general consumption.
Maybe what we can do is to get someone or a place wherein we can dump some code. Right now there isn't much but looking for an active OACS contributor and emailing some code. Can someone volunteer to to be the main integrator to the tree? It would be nice if we can put up a single web page with the info. Just a simple page so we don't have to dig on the bboard.
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.
The code dump yard will have code that is pulled of a project that may or may not work. A description what the dump is. Atleast the other coder wont have to go into the yucky hurried up code.
Now the problem is where can we dump this code and who will semi maintain it?
Or maybe we can do without this and just have a well known way on how to contribute code back to the source. But I think based from experience this does not happen to well since my code is crap. I want to give nice code and can be used by others too. Normally we dont have time and too lazy for that. So I guess a code dump site will be good. Those who are not lazy enough may find gold on someones trash.
Please let me know about your ideas on how such a dump for site code should look like.
Thanks very much I think here are what would the community will need
- prominent link from openacs.org to your code dump site
- ability to upload targz
- abilitiy to attach a description to the dump
- ability to untargz the file once its uploaded. We would not want a new developer downloading a big tar ball only to find that its all crap. The developer should be able to browse the code.
- ability for the new developer to download the targz
Why not just create a CVS and use cvs web or something. Each dump will be a new module. Simple FTP should be fine too. And we just Standardize on the dir:
[code dump dir]/description.txt
[code dump dir]/dump.tgz
[code dump dir]/[dump name]/extracted code.
I guess anything will do. After all this is a donation to the community.
- 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)
Most of us have some code which would be useful to others. The problems of it being "a bit hacked together" or "not generalised enough" are very common. Now how to get around these problems. What about this for a win-win situation: If I'm looking for some particular functionality and you have it. We need to be able to find each other, then I can take the raw code (and docs) and use it under the following conditions - I will generally spruce it up and generalise it. Then I will give it back to you and the community. If this takes less time for me than building the thing from scratch then we all win.
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.
I am thinking here of what the Affero General Public License does: there is a small link at the bottom of every page of their web service that links to the tarball of the code running the web service. See http://svcs.affero.net/join.php?lg=1 at the bottom right hand corner.
To make this a default feature of the OACS-- download the most recent tarball of the code running the site (without content) would go a long way to supporting code sharing with a minimum of effort on everyone's part.
It would also do a lot to allow up to release the "vertical releases" discussed many months back (ecommerce, dtolrn, etc).
Of course anyone using the toolkit could turn off this "feature" if they want to keep their code additions and modifications proprietary.
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 .
But for sheer viral marketing potential, it would be a very good feature. Now, of course, I have to put my money where my mouth is and put out a proposal (I'm not a developer) and I'm not quite _that_ in love with the idea yet. ;)
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).
Just by playing with /directory I realize that there are many "old" registrations (change of email address,
etc). Is there a way in OACS to remove yourself? Can old entries (not used for 6 months) be spammed (to use
or remove). can the admin then finally get rid of the them?