Home
The Toolkit for Online Communities
16706 Community Members, 1 member online, 2317 visitors today
Log In Register
OpenACS Home : Forums : .LRN Q&A : Why not publish .LRN source code used at Universities?

Forum .LRN Q&A: Why not publish .LRN source code used at Universities?

Icon of envelope Request notifications

I don't know, this may be a very radical idea, but I was thinking that
when working with .LRN (for example when fixing bugs) it would be very
useful to be able to access the sources used at various universities
(right now that means Sloan and Berklee and possibly others that I
don't know of).

For example if we run into a Postgres bug we could check first with
the Berklee code base if they have fixed it already, likewise with
Oracle and Sloan. When adding a feature you want to check easily if
some other University has already added it.

Does this sound like a good idea? Setting up anonymous CVS access with
pserver shouldn't be too much work. If we want to reap the full
benefits of Open Source I think this is what we should do.

Peter,

THis is not a bad idea, but what we really want is to have the users push the bug fixes back into dotLRN CVS.  So setting it up to make it easier to submit bug fixes back to dotLRN would be a better solution.

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.

I have a couple of questions.

Are you proposing that the code that is live (including their customizations) on the different universities?  Or a code base maintained by the universities which is based on the vanilla .LRN (ala cvs branches)?

If it's the former, then I guess that's going to be complex because to look for a certain fix then the coder should checkout N+1 set of codes where N is the number of Universities participating.

I think the latter sounds like a better idea.  Although the drawback is that it will be repetitive on the part of the university coders because they now have to track 3 code bases (official, their live version, their shared code base).

My suggestion is to have several branches.  Then, designated persons from the universities would be given admin rights to a bugtracking system.  So all the participants do would be to check the bugtracker regulary, see if they've fixed that bug and update the bugtracker entry stating that it has been fixed in "this" branch.  So it would have a "status" of "for merging".  So the main integrator of the official .LRN should just check the "for merging" bugs and do his stuff.  Now, dedication and discipline comes to mind if you want this to work. :)

I for one would be very interested in being able to do a checkout of the tree behind dev.openacs.org, just to see how the highlight boxes (Recent Posts, News...) on the frontpage are implemented with cacheing, to see the master template code, and so on.
Bjorn,

Your wish has been granted!

You can check out the dev.openacs.org code from the OpenACS repostiory.

cvs -z3 -d:pserver:anonymous@openacs.org:/cvsroot co openacs.org-dev

If you get a password prompt, hit ENTER.

Thanks Dave!  :-)
Thanks for opening up the OpenACS site Dave! Now I'm hoping that Sloan and Berklee will follow suit...:-)

Deds, I am not proposing setting up new code bases (repositories), but rather an opening up of the existing ones. Doing so does by no means increase complexity and it should not be taken as an excuse for not merging improvements into the official .LRN code base. On the contrary, and this is exactly my point, the increased openness would accellerate the merging of improvements back into the common code base.

Jeff, thanks for agreeing with me (:-)) and for pointing out the Greenpeace example which is a really good one.

I didn't really twig to what you were getting at originally, but I think I understand now.

Are you suggesting that sites built on OpenACS might offer a kind of 'get the source of this site' function, so that interested parties can see how its built, use it as examples, and so forth?

If so I can see some merit in this.

The client benefits from peer-review, the toolkit benefits from more bugs found in *real* systems.

The only problem I can see is the many of my clients might be a bit reticent to do that. And that is because no-one has solved on of the potential problems of open source deliveries.

If a client is gaining some commercial edge from their system, are they really likely to want to give their competitors a head start?

Ultimately, once a custom system is created, if someone's business depends on it that's a big dis-incentive for opening up...

I suppose this is perhaps not an issue in the Academic world.. although correct me if I'm wrong

Simon, your interpretation is correct. I understand of course that your average corporate customer will not be inclined to buy into the idea for the reasons that you mention. However, many educational and non-profit organizations adop  dotLRN because they sincerely believe in Open Source (I think this applies to Sloan, Berklee and Greenpeace). Opening up access to source code is at the heart of the Open Source idea and would therefore seem like a natural thing for these instituations to do.
Incidentally, I'm not trying to give the impression that commercial companies aren't fully committed to open source. We are, and many of our clients share that view...

But obviously businesses do have to compete to make money. :) Perhaps if the toolkit included functionality that made it easier to open up 'sections' of sites.... ?

Simon, no doubt there are a lot of people who won't (or can't) open up their CVS repositories. On the other hand, most dotLRN clients (and dotWRK clients when they exist) could. If someone is deriving a commercial edge from the systems they have written and they choose not to release the code that is their decision to make but the truth is the vast majority of internally developed code provides little or no competitive advantage.

It is hard to imagine a place where more money is invested in IT and there are ostensibly more reasons not to share code than in bond trading at investment banks but there have been quite a few initiatives to pool code, the biggest example I am aware of being EJV which intended to build a common infrastructure for managing fixed income securities data and modeling (and which failed but that is an unrelated story). Also, openadaptor http://www.openadaptor.org originally developed by DKW (or whatever it is called now) was open sourced. It is precisely because the banks end up spending so much money on building common infrastructure that factoring out what does not provide competitive advantage and sharing costs is so appealing.

We are all about communities and collaboration and we have a great platform from which to launch such an initiative. We should be helping provide the tools and information to do so. Rather than quoting the old chestnut ("they can't because it's their competitive advantage") we should be encouraging people to think very hard about what they can open up and more importantly what they can contribute back to OpenACS and lauding the people who take the initiative to do something about it.

Jeff,

Urmm... I'm agreeing with you. What I'm saying is that we don't live in a wibbly wobbly world where everyone is magnanimous and can 'see the light', I was therefore hinting at providing facilities that encourage sharing whilst building confidence in more conservative middle managers that they're not opening themselves up for future problems..

And also, the examples you cite are mis-leading a little. Deutsche Bank (I use them cos they're linux-pro now) are a bank... they're business isn't software. so yes for them the same pressures to 'close' their technology don't exist, but when you business *is* software this is not always true.

I do agree with you, but lets not pretend open source is a panacea.

We are working earnestly to get the Sloan code incorporated into the dotLRN CVS. We also plan to provide anonymous CVS access soon to our code base for anyone who is interested.