Forum .LRN Q&A: Why not publish .LRN source code used at Universities?
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.
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.
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.
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. :)
Your wish has been granted!
You can check out the dev.openacs.org code from the OpenACS repostiory.
cvs -z3 -d:pserver:email@example.com:/cvsroot co openacs.org-dev
If you get a password prompt, hit ENTER.
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.
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
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.... ?
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.
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.