Sakai is another open source e-learning system or LMS, it's being used in about 70 schools around the world. Even that the number of installations is ridiculous compared to Moodle, the choice of IBM will unbalance some decisions from now on, and it can become much more common, as you can imagine.
IBM will sell universities, and schools the servers ready to run SAKAI, and thus get good revenues.
I think that Moodle needs to have an eye on it, maybe not as a competitor, but to observe how it evolves, which are the standards it uses and maybe if both can share courses or contents.
Yes, I took a look at its site, and noticed Sakai has a different community/economic structure than Moodle. Members are universities (about 30-40) and are charged $10,000 for a three-year partnership. The partnership arrangement allows them access to the development team and participation in the design of features/modules. In addition, there are commercial partners, like IBM, with a different arrangement that I am not clear about. The code is open source.
Be assured that Moodle does have an eye of Sakai, albeit only from a curiousity perspective. Since both projects are open source there is hardly an issue of competitiveness at stake. Sakai at this time has only a fraction of the traction that Moodle has going for it in higher education and elsewhere, and seems to be about where Moodle was in 2003 with its feature set. Recently an integration was done between Sakai and the open source uPortal content management system, which uses the same Java platform language.
One of the Sakai board members is a friend of mine and I meet about every 3 months with him in Washington D.C. so that he can learn more about Moodle (he's a big fan), and I can learn what is happening in his universe. Sakai is funded by Mellon Foundation, at least for the next year. There are strong expectations that Sakai will show more results in the coming year in terms of the learning experience students are having with it (quality assurance standards). Sakai right now has 70 academic partners that each pay $10k US per year to remain in the program. Development is overseen by the three principle institutions that started the project, and this has shown itself to be a real problem as students involved in the projecct move on and get real jobs after graduation. In contrast, Moodle has a central person (Martin) who is passionately dedicated to Moodle full time, and a cadre of contributing developers that all have similar feelings.
The concern I have is that Sakai's adoption and promotion by flagship Us will eclipse the fact that Moodle is already a viable alternative that can hold it's own now in features, ease of use, and ease of administration.
Agree completely with everything you say. It sure doesn't hurt when you have those big donar dollars behind your name like Sakai; makes the spin factor go easier. Just this morning my friend on the Sakai board e-mailed me a PDF of the excellent report from Humboldt State University detailing the Moodle comparison with Blackboard. At least they are paying attention to us, that's for sure. There are plans afoot to offer higher education a buy-in to Moodle with significant support. This year I think we will close the gap, if one exists.
I am very glad to hear of any efforts to make higher education partnership system with Moodle. I know you have been active in fund-raising, the donations we get are actually just a trickle, and what we need to give Martin and this community is a solid, dependable stream of income that can fund a leap in development efforts. The bazaar approach is wonderful, but the person in the middle trying to integrate all the contributions is now stretched to the limit.
"Sakai is Java, where as Moodle is LAMP, not a
lot to choose between them at the moment but into the future Java promises
to give a more stable system(one of the unanswered questions about Moodle
is its stability in very large installations) "
"Additionally, if you look at its pedigree and the level of existing and
future investment it has all the advantages of FLOSS with the addition of
major US respected universities investing and using it"
Would you have any responses to these points? The E Learn committee meets this Wednesday to make a final decision.
Just off the top of my head about this:
1. Java has some patent issues with Kodak.
It may or may not affect its development. However, it is in question. There are none of those problems with PHP.
2. Big universities, big bureaucracies, big egos. As Bryan mentioned in this thread, for the money and time spent they have not much to show for development. This has to do with the politics between the universities resulting in the snail's pace of development.
Bryan has touched more salient issues in this thread. You can read them here:
That we know about, anyway.
There are a lot of "submarine" patents out there. For example, Forgent has recently asserted that they have patent rights in the JPEG image format, and are busy suing everybody in sight (starting with the deep pockets, of course). Ironically, one of the companies that Forgent is suing is Kodak.
I wouldn't bet money on PHP being 100% safe. There's a lot of code in PHP and the PHP libraries, and there are a lot of bogus patents on the books.
Sun paid off Kodak, btw, so that particular case is no longer an issue.
Google and Yahoo use it.
Google runs Python and Yahoo runs PHP.
Who says PHP doesn't scale?
Many very major web sites are now using it.
IBM seems to think it's a major direction.
Google "IBM and PHP".
Who says Moodle already doesn't scale for your campus?
Modest implementations will clearly work.
Who says Sakai (or anything else) scales?
I have yet to see verified numbers that are at the 100,000 users
+ significant quiz/gradebook usage. That includes WebCT and BB.
Could be that I haven't heard of it, but again I'm skeptical ANYONE
can scale with a single deployment. In any case, don't assume
anything CAN indeed scale, ask for verified benchmarks.
Who's got books written about their product?
That's a measure of overall interest in the market.
I would look at O'Reilly, for open source style products.
Joost J. Becking
educational technologist & open source expert
I don't know exactly about the scalability of PHP. Do we have any particular numbers?
Let's look at programming languages used by BlackBoard, WebCT, and Sakai (I'm not sure):
- BlackBoard: Java + Perl
- WebCT: Java
- Sakai: Java
Could we ask a question about the scalability of BlackBoard, WebCT, and Sakai?
I say Michael Radwin talk at OSCON 2003, Yahoo looked at a number of languages like perl, asp, jsp, etc. They chose PHP.
Martin H's projections of >350,000 users on his 4 unit Moodle cluster are pretty exciting numbers if you like LMSs that scale, also..
All of Yahoo, Google, Amazon and eBay services are implemented over different variations on LAMP, with some bits in C. Is that not enough?
For Moodle, maybe. For LAMP in general, no, it is not enough. Remember this is about comparisons and advocacy. Being right about something isn't enough.
Saying that Google&Co. can get LAMP to scale doesn't prove that I can get LAMP to scale. Does anyone know how much they have tweaked and customized their platforms? Google is much better at their stuff than I am at mine.
I haven't had to do much LAMP advocacy yet and I hope I won't have to. Mainly because I don't know about LAMP (well enough) the usual things I would base my argumentation on.
What computational models does LAMP support?
What is LAMP execution model like?
Why does LAMP scale?
What in the LAMP stack is the reason for its scalability?
(I did google a bit for the answers, but didn't find them. The ActiveGrid application server seems interesting, though.)
When doing Moodle advocacy in my neck of the woods I usually say that Moodle will scale and use your work with NZVLE as the proof (BTW, big-big-big thanks). So far I have not been pushed on that point, nor do I expect to be as 30k users is as big an installation as I expect ever to see around here.
It'd be too long to explain the ins and outs of LAMP. It's well documented elsewhere, and understanding why it is ahead of other stacks is a pretty long-winded exercise.
LAMP is scalable, and you can hire people to tune things. You don't need to have the expertise in house. It's good if you do, but it isn't required. You can hire a Moodle Partner, or just look around for people with experience tuning LAMP-app webservers. Experienced mod_perl hackers are particularly knowledgeable about it, and generally anyone who was in charge of a high-traffic LAMP webserver ~5 years ago has the knowledge (because back then RAM was expensive, so you really had to know about it!).
On the other hand, Java is extremely resource intensive, and doesn't scale very well. Well designed Java web apps can scale if you through a LOT of hardware at them, and that is the best you can hope for, and apparently .NET has a similar profile.
How do I know? Because no-one in the whole industry manages any better -- they all end up with huge server farms. Not even Sun or Apple with their newfound love of Java.
In the end, you can always hire a subject matter expert -- someone with the appropriate credentials -- and trust his/her recommendation. Or commission very expensive benchmarks.
Being right about something isn't enough.
Then don't ask for technical arguments, they won't matter. Print something on glossy paper, and charge them lots. I mean lots. Aim for at least 50% more than the BlackBoard licensing costs, so they know you really mean business and should be taken seriously. I'm sure you'll get the project
Then don't ask for technical arguments, they won't matter.
Being right about something isn't enough.
Strangely enough, that is not my experience, although I am familiar with the effect a high price has on people who are ... out of their depth. In most cases, I have found it essential to have a solid technical foundation for my arguments. This must be largely a matter of style: refusal to be cynical has become my lifestyle .
I would never recommend using LAMP (a contender) without explaining (proving if possible) why LAMP works, if there were a slightest chance that a J2EE application server (the current champ) based solution was being considered too. Somebody from the J2EE crowd will say "LAMP doesn't scale" and if I have only said "LAMP scales" than it's a tie and the champ keeps his belt.
Actually, no LAMP/Moodle vs X required. VirtuaaliAMK of Finland (a national e-Learning effort) is offering its members not already using Moodle a chance try it out on their installation. It would be totally reasonable for one of them to ask tough and detailed questions about scalability and not be satisfied with "it scales". Not your problem, not even mine strictly speaking, but maybe my opportunity to give something back to the Moodle-community.
It'd be too long to explain the ins and outs of LAMP. It's well documented elsewhere
A pointer or two to those elsewheres might be useful for future reference. I like dead-tree versions too.
Some interesting tidbits I came across:
The J2EE guy still doesn't get PHP (blog)
PHP scalability and performance (blog)
Only thing missing is a "Container" (blog talkback)
1) Who says ANYTHING scales?
I have yet to see verified results of scaling from ANY vendor. This includes
WebCT, Blackboard, and our current LMS Desire2Learn.
2) Should we really expect something with a large DB to scale?
Just keep in mind, all performance curves are J-curves.
A single BIG deployment, with a single BIG database is asking for trouble.
The bottleneck is on the DB. This not so much a flaw in databases
as is it a flaw in the expectation of scalability.
3) Commercial Web Hosting scales
Look around at major commercial web hosting services.
Here's one, http://www.1and1.com
They obviously think that LAMP scales. This is how they can
charge $5-$100/month per site. Of course they are running multiple
sites on the same server.
Moodle was designed to run on this style service.
4) Active Grid has a different model of scaling, similar to Commercial Web Hosting
You noted that in an earlier posting, http://www.activegrid.com.
I think we should explore how to scale along these lines.
STAY AWAY FROM COMPLEX DATA MODELS
is one conclusion I come to.
5) The Burton Group recommends P-Languages
I first caught wind of Active Grid from a Burton "white paper" on the "P-Languages",
here's the URL to the abstract http://www.burtongroup.com/research_consulting/publicdoc.aspx?cid=14 You will have to have a subscription to read it.
I would highly suggest getting a copy if you want to have credibility with the doubts.
6) Let's scale with lots of node of Moodle, The Moodle Org Unit model
Instead of putting an entire campus or maybe an entire university system into
a single instance of an LMS, I will call for a new model that breaks up in
to "org units". Let each one run independently and "own" it's own database. The linkages are lightweight, loosely coupled. On top of this, run a "portal" that
is your "view of the entire enterprise". If we did this with Moodle, why you'd
have a Moodle Org Unit (tm) (and Martin, I hearby grant the trademark to you!),
or MOU for short.
An implementation consideration here would be the granularity of the MOU would be a important choice. I will suggest the Department is the right choice, as this matches how we are organized, though I could see an argument for other choices.
In any case, this will scale to ANY size organization, at least in Higher Ed, as you just get more departments as you get bigger (at least from what I see in the US and Canada).
If (as Martin L reports here) a 4-5 box cluster can scale to ~350,000 users without hitting a j-curve, seems to me that we don't need to look at other solutions--for scalabilty reasons (there may well be other reasons) until we're looking at a larger number of users than that.
Seems to me that the main issue is where is the db server performance stop scaling? If a well tuned, powerful db server's limit is above 350,000, then where is it?
If I look at my current metrics and multiply by 10, assuming linear increase in load, it'll handle it. But Dirk is right in the inverted J-curve thing. Things scale, and everything looks linear... until it hits capacity, then it gets hard, hard, hard to scale.
(So you can say I was a bit, erm, unhumble, in a moment of weakness.)
So there are bottlenecks we can fix, and there are bottlenechs we can't. And the ones we can't are is in database write concurrency.
So, we do have a reverse J-curve today, yet based on the data I have I think I am the beginning of the slope, and there's a lot of scalability in today's Moodle. It will hit a ceiling, but I am working on moving that ceiling higher.
In particular, I want to cache 70~80% of our database calls by using turk-mmcache and memcached. Currently Moodle is very 'chatty' with the DB server, and that murders the database on high-traffic sites. Using in-memory caching means that (cheap) extra RAM can be used to ease the pressure on the DB.
considerations here, which can be revisted in the light of "software that
doesn't get licences per CPU".
However, I also think we should move to another whole thread, honoring
MDs request earlier. Let me repost some thoughts on this MOU thang
Hi Jussi, look up Yahoo's Michael Radwin and investigate his various works on the subject (for instance: Making the Case for PHP at Yahoo).
He is the engineer who led the team that took Yahoo to PHP, his team did a good deal of looking at various solutions for a high volume website with a good deal of user interaction (logging in, posting, shopping, etc.).
PHP Scales is also a good article, I think, with info. from the originator of PHP, Joyce Park (who converted Friendster from java to php for scalability), etc. Goes into some pretty decent depth.
I think PHP scales well because Apache scales well because the Web scales well. PHP doesn't try to reinvent the wheel; it simply tries to fit into the existing paradigm, and this is the beauty of it.
Chris Shiflett has been developing Web applications with PHP for a number of years and is currently working on O'Reilly's PHP Security Handbook.
In my experience PHP can definitly scale, as I used to work for a news site that processed truly huge volumes of requests. However to do this the system was highly customized and tuned. At the other level Java is not a good solution for delivering dynamic content through shared space as the requirments of the virtual machine limit the number of services that can be delivered per MIP/CPU/MB of RAM. I spent a year or so developing a Java based solution and eventually switched to PHP as I could not find reliable Java/JSP hosting at a reasonable price. This meant re-developing a huge amount of work, but I have had no regrets.
Conventional wisdom has it that at the truly high scale Java has the edge at scaling over competing technologies, but I suspect that there is no reliable and documented proof that it does so any more than the equivalent PHP stack.
The quote about the scalability comes from an article I wrote for the Polish magazine E-mentor. I've got extensive experience through my active involvement in implementing dozens of ELO's over the last 10 years, including PHP-based ELO's. Also, I'm board member of the Didactor Foundation, a Java based open source ELO and I do a lot of lectures about Open Source in education. So, I tend to think that I know what I'm talking about.
The remark about the scalability is not so much of a technical remark (please read the article so you understand the context), as well as a remark from an organisational point of view. PHP is easy to start of with, Java (and .NET) are typically not. There is a reason for this: the logicality of Java is harder to understand because it requires knowledge of objects and their relations. Once you've got a learning environment based on Java going, it's easier to make adjustments, add new components or, for instance, integrate IMS-ld functionality.
Why? because IMS-ld, as well as other new learning approaches, are based on the thought of objects (like knowledge, people etc), relations between objects, combined with a certain workflow. It's my experience that in this sense Java is more scalable because it's based on the relation metaphor.
This doesn't mean at all that PHP is not scalable, but looking to the future, I expect that it's not as flexible as it should be in order to adopt to the continuous changes based on didactic experiences.
I'm open for any discussions
The remark about the scalability is not so much of a technical remark (please read the article so you understand the context)
I assume you mean this one: http://www.e-mentor.edu.pl/_xml/wydania/9/149.pdf
The only place I can find you mentioning scalability is in the paragraph where you declare that Moodle's usefulness is limited by PHP's scalability: "but when things get bigger and more important, organizations tend to look at other, more scalable, software".
That certainly implies to me that you are talking about scalability in the sense of a language's ability to handle high ('bigger, more important') user loads.
However, it is unique as I've never heard 'scalable' applied to Moodle in this context before, generally it seems the consensus is that Moodle will always be easier to develop for, the usual question java advocates raise is whether it will be able to scale to 10,000s of thousands of users. NZVLE having put this rumor to rest in practice, I guess the next thing will be to compare development times , say the time to develop new translations, gradebooks, other 'learning objects', etc. In fact as Martin Langhoff and Dirk Herr-Hoyman have well demonstrated here, the upper limit user load scalability of an LMS is (presently) limited by the speed of the database server, not by the language. Different languages may however cost more or less to get to that db saturation point, and that has a direct bearing on the resources available for the development of new tools.
At Cal State, Humboldt, we've developed a number of new components and modifications for Moodle over the past 2 years, and have found the code very easy to work with. When you look at the relative amounts of time and money being spent on development, it doesn't look like Sakai is realizing the efficiencies your theory says they should be able too. Maybe that is for other reasons. It's harder for me to evaluate if Didactor is in the same league as Blackboard or Moodle as I don't see a feature list on your site, nor can I find it on the edutools comparison website? Does it have a gradebook? If so how long did it take to develop it? Does it have a quiz module? If so, how long would it take to develop new question type for it? (I ask this because these are some tasks I can put numbers to in comparison to Moodle).
One of my concerns about Sakai in particular and J2EE in general is that it appears that scaling it to handle thousands of users will cost much more than scaling Moodle in particular and PHP in general. This involves both greater hardware expenses, and as you mention higher (and more specific) levels of knowledge of the staff. This means that there will be less resources left over for the development of new teaching tools. Since it appears in my estimation the hardware/staff costs will be 2-3x as much for running a J2EE/java LMS (Sakai) as for running a PHP one (Moodle), the java system would have to be much at least that much easier to develop for in order to break even.
In short, if a system costs more to support there will be less $ for development, so scalability in terms of cost/user has a limiting effect on the relevance of scalability in terms of cost/development.
Perhaps Didactor scales more efficiently than Sakai in this respect, how much in hardware and staff costs would take to run Didactor for a 35,000 user University?
By the way, the Didactor site appears to be only in Dutch, does Didactor support any other languages?
I'll try to answer your questions,
Didactor is developed by institutes for vocational training, a university, a broadcasting corporation and a couple of healthcare org's. The Mediator Group initiated Didactor. Over the last 2 years we've had four releases and about 4 people have worked on it fulltime since the start. A lot of others have contributed to the project parttime.
It does have a quiz module with 8 quiz formats and, with the built in editors, it takes a couple of minutes to create a new quiz and a couple of hours to create a new quiz format.
About the hardware: Didactor runs on a single server, it's database independent but most of the time people use MySQL.
About the costs: in the end, it all comes down to a price per user. It's true that Java is more diffcicult and has a stepper learning curve, but once you know it, you can develop just as fast as with PHP. The total cost of ownership is lower than with other ELO's, but of course the effect of open source comes into count here as well.
Didactor supports other languages, through a simple XML-file it takes about 30 minutes to set up other languages.
It's not clear to me that using an object oriented language is in an of itself a good thing that leads to reuse and scalability. The idea is that you build up a set of objects and reuse them over time. I will claim that this amounts to a framework,
and that building a good framework can be done in multiple ways, one of which is object oriented, but it's also possible to use shared libraries. You really have to
come up with a clear "model" for how things work and define boundaries.
I've only see good frameworks happen over time, thru several iterations of code release. Perhaps one of the most sophisticated frameworks I've seen was written
in M, a time oriented, object like language, within a medical records info system.
I hit it at year 15 and perhaps 5 major releases of the product.
I'd like to say the object oriented is a good way to do things. One of the first truly object oriented products in the commercial realm was NeXTSTEP. That didn't take the world by fire, perhaps ahead of it's time, perhaps priced a bit too high. One of the neat things to come out of NeXT was WebObjects, which is still an Apple product you can get for the Mac. WebObjects is pretty cool, once you get it. The learning curve is awfully steep. I've seen at least one major project in Higher Ed IT get cancelled due to issues using WebObjects (my.umich.edu), with one of the larger issues being that they couldn't get enough WebObjects developers.
What I really think is it boils down to good design and good abstractions, which
you can do with a programming language that supports functions or objects.
Now, whether you have a good design for reuse only has some impact on performance and scalability. Here you have to look at how things perform
in the field or under load. Bad algorithms will get you in trouble, no guarantees that using Java or PHP will keep you from a poorly performing bit of code. At the end of the day, this all has to run on the same CPU, memory, disk, and network, with whatever capacity is available.
When Java 1st came out, it had a reputation as a poorly performing language. It's better now, as there has been some time to tweak it. However, you can generally do much better using a so-called native language, like C or C++, or for that matter in assembler. The reason we don't write in lower level lanaguages has to do with cost and benefit. It's so much faster to create and to maintain, and the loss of performance is not to severe that you can't live with it, which is to say it's cost.
I've been involved in some large Java projects on our campus and did champion brining in one of the 1st large Java-based products for our portal in 2000.
I think Java can be a fine choice for some things that are realively low level.
PHP is now thought to be a pretty good choice for web applications, having been brought into live for just that purpose. And the big reason it's so popular is
the huge library of shared functions. That's a framework for building web apps. One can whip out something that's fairly sophisticated pretty fast, because mostly you are leveraging the PHP library. Same thing is true for .NET or Java, they too have their own libraries.
One could argue the merits of PHP vs. Java vs. .NET for creating web apps. I prefer
to look at results. PHP is a very popular choice, much more popular than Java, and a bit more popular than .NET. I wish I could cite some hard evidence/survey. the best I can do is cite the popularity of PHP in web hosting services (more than either Java or .NET, both of which will tend to cost more). For a very large PHP app, look at Yahoo, I'd say that scales pretty well. Or Google, which is a Python app, and that scales pretty well too.
No doubt someone could write a Java app that scales well. However, I have also seen Java apps that don't scale well too. Or PHP apps that don't scale well. These are problems as much with the algorithms chosen as anything.
On the point of what's going to be more flexible in the future in response to teaching needs, I think that PHP looks pretty good. It's simplicity fuels experimentation by those that are not "rocket scientists". Or to paraphase someone, "you can make mistakes faster" and correct them faster too.
I think you're right, in the end it depends on how the framework is set up from the beginning and the quality of the code and the people working on the project. It might even be bad luck that the PHP ELO's I've seen were set up in such a way that when things got serious they weren't manageable any more.
The reason we chose for Java was the object orientation though, the principle of technical objects met the learning object philosophy wonderly well that I expect that Java, if used in the right way, will keep paying off. Future will tell.
With the present state of Sakai, it seems to me that is all it would take to show that Sakai is very pre-beta with many critical LMS features missing or poorly implemented (the forums being the worst), while Moodle is a mature product, ready to go out of the box.
<i>to give a more stable system(one of the unanswered questions about Moodle
is its stability in very large installations) "</i>
I think New Zealand Open Polytecnic has 35,000 currently online, Look for posts by Martin Langhoff and Richard Wyles about this. More info about scalability here. There are several other Moodle institutions in the mid to high 20,000 student range. The largest "Sakai" installation I know of is UofM, (I think they are actually still running Chef, Sakai's predacessor, but similar code) is 27,000 students, and they are reported to use 27 (!) servers to accomplish this.
PS how does "in the future java promises to give a more stable system" compute? Surly java has been around long enough for it's stability to be known? Surely Yahoo's decision shows that PHP is more stable and scalable? I don't think there are any java/jsp sites the scale of yahoo?
I do know the java and tomcat problems are one of the biggest problems we have here with our outher LMS, Blackboard, maybe the java side of BB just isn't implemented well, but java and stability are two words words that don't fit together in my experience.
Can you cite a source for this?
I posted the ? over in the Sakai forums to see if I could get some more info.
PS, now that I have a Sakai discussion window open reminds me, given their 'refresh the discussion every 10 seconds' mechanism, I would expect that one would need a good deal of iron to keep that running for a larger scale install.
Also the page http://status.itcs.umich.edu/index.php?type=allprevious reveals quite a few outages in their CTools Sakai pages.
- developer environment
Hardware: PowerPC 800Mhz or higher, Pentium 2Ghz or higher, 512MB RAM (1 GB recommended)
- small production site (<200 users)
Hardware: Pentium 2Ghz or higher, 4 GB RAM, Linux Apache + MySQL
- medium production site (<2000 users)
Hardware: Pentium 3Ghz or higher dual processor, Linux Apache server, 4GB RAM
Pentium 3Ghz or higher, Linux MySQL server, 4GB RAM
- large production site (>=2000 users)
Hardware: Pentium Apache server cluster + Oracle database server
No wonder Blackboard/WebCT aren't worried about Sakai.
ISIS works an release candiate 2
1.5 due out in Dec.
Michigan only one really using it. 27 fairly hefty servers
Big effort is Indiana now
OKI stuff not in 1.0, hoping for 1.5
With the present state of Sakai, it seems to me that is all it would take to show that Sakai is very pre-beta with many critical LMS features missing or poorly implemented (the forums being the worst), while Moodle is a mature product, ready to go out of the box.
Agreed. I've been hanging out in the 'dev' course of SAKAI and the tool isn't there yet -- hell, it's barely out the gates. The 1.5 thing is clearly version number inflation (evil edit: to put it ahead of Moodle version numbering?). That in itself may be an indication of priorities, hopefully not.
I don't think there are any java/jsp sites the scale of yahoo?
There aren't, of course. All the big scalability game is using different LAMP variations: mod_perl, mod_python and mod_php on Apache. Databases see more variety, mostly mySQL or Postgres but also some really high-end stuff sometimes. This is the stuff that powers Yahoo, Google, Amazon, eBay... and Moodle.
As you rightly say, there's been enough time for all the tools to mature and show their abilities, Java included. And Java's scalability isn't there, and variations on the LAMP stack are what is being used industry-wide.
WRT the NZ cluster: it is hosting several campuses now, though none as large as the one for The Open Polytechnic of New Zealand. And it's working just fine on 4 finely-tuned servers. Last week I was running projections on a 10-fold usage, and the conclusion I arrived to was that we need larger hard drives, and perhaps an extra server assuming performance doesn't improve.
And I mention that because as traffic has increased, server load has decreased, month over month, because I keep finding things to tweak
Amazing! Where can I order the "Martin Langhoff Guide to Moodle Server Tweaking"?
[Hint#1 (p.27): Don't borrow the same tables for one module that you use in another.]
I have ordered two copies of each. But check out Amazon.com for even better versions.
I think people are joking ;)
There isn't a Martin Langhoff Performance Tuning Guide yet. But if you read old threads in the Servers and Performance forum, and perhaps ask some questions, you'll learn a thing or two about server tuning.
Although there is a hidden message in MD's linking to the download page, I suspect. Download the very latest 1.4.5+ to get the best performance -- all my PHP code tweaks end in Moodle. Read the release notes and config-dist.php -- there may be some clues there.
I've also added a few tricks in 1.5 for developers and admins to have an explicit feedback with key performance indicators in each page. A tight feedback loop is way more effective than me whining about bad performance.
About how many users do you have on the NZVLE cluster now?
Additionally, if you look at its pedigree and the level of existing and future investment it has all the advantages of FLOSS with the addition of major US respected universities investing and using it
It has none of the characteristics of FLOSS, except the license, and a problematic one at that. Many Linux distributors don't consider the license "Free", and you can count in distributors to understand the license game better than anyone else -- their business depends on them.
I posted before on this thread: SAKAI is old-style cathedral development, invitation-only club, with a somewhat free license on top just because it's fashionable.
I think that many of the substantive considerations have been raised. I am aware of the impressive work that Richard Wyles and Martin Langhoff have done in NZ with the Open Polytechnic regarding its Moodle deployment. Significant investment has been made in scalability and at no point was there ever any mention that scalability was a LAMP risk (the Open Polytechnic does not use MySQL in any event). Martin is in a much better position to discuss details.
It would seem to me that different organisations will have different decision drivers that will dictate the weighting of particular system characteristics. Technological requirements are not necessarily more important than ego, political, or partnership requirements from an organisational perspective (at least during decision making, if not during deployment). I am currently in the process of shifting professional roles to a much larger institution (than the Open Polytechnic) that is a Sakai partner, which is still evaluating infrastructure options beyond traditional LMS functionality. From my perspective one of the potential appeals of SAKAI is the more or less general discussion around its service oriented approach and its relationship with OKI. This has been reinforced in the recent IMS public dispatch
announcing closer collaboration between IMS Global Learning Consortium (IMS/GLC) and MITs Open Knowledge Initiative (O.K.I.) regarding the change process for the next release of the Open Service Interface Definitions (OSIDs).
On the other hand, as has been pointed out in this forum, the Moodle community tends to be very transparent and the application is a relatively known quantity (perhaps more so than any other LMS in existence).
I am not sure if this is the appropriate forum space, but does anybody have any thoughts about how the whole SOA/Standards/Open Frameworks constellation of issues might fit into LMS comparison processes? How it might be framed realistically and intelligently and its importance assessed?
I am new to this forum, so if this discussion has already happened, please feel free to point me to it.
I'm here in Madison, WI at an IMS meeting, which I'm hosting, for
the Tools Interoperability project. This is a "loosely coupled" web services
technique, just a first pass. It's IMS's 1st try at such a specification.
Our local team decided we could get Moodle
into this demo, at http://www.imsproject.org/altilab
Well, we are IN and Moodle will be demoed there too.
We did have to put in a Java/Axis service "on the side".
No reason to think that Moodle can't interoperate with Sakai. Why not.
No reason to think that PHP won't move forward with better WS in version 5
This is but the 1st stage for the IMS TI. More of a proof-of-concept and new direction. It's before you get to SOA and a very highly distrtibuted deployment.
I should also note that OKI has released PHP bindings. See http://harmoni.sourceforge.net/, as well as the main OKI site at http://www.okiproject.org. This is what IMS is now maintaining.
An Open Source license isn't all there is to FOSS. Ilias3 is developed in an old-style cathedral approach -- and I learned that when I tried to help them fix some problems. Moodle is a successful bazaar, and it has a strong leader in front. The leadership factor is key, because it acts as a catalyst (pun? nah!) for collaboration.
Players looking at FOSS need to understand the FOSS 'metrics' to evaluate a project. It is normal to evaluate the financial soundness of a supplier, its track record, satisfied customers. No different with FOSS -- you evaluate the installed base, developer base, how development balances conflicting interests, life of the project, low barriers of entry for contributors, open design approach and the tone and spirit of the dev and user forums. In short, you evaluate for bazaar-ness.
SAKAI and Ilias fail on all of those. ATutor is making the transition from cathedral to bazaar. Moodle has been a successful bazaar for a while, and the (huge) changelog for 1.5 is proof of that.
Lately, I haven't been able to hack on Moodle a lot, as I've been working on a huge code merge between Eduforge and the GForge project. The GForge project leaders aren't as enlightened as Martin Dougiamas is, they are clearly not interested in nurturing their dev community. They are defensive, and reject most attempts to help -- they have their little cathedral in-house, and it external developers trying to help with anything of significance are a threat.
There is a lot of work MD puts into nurturing this community. And it is working -- I'm really admired. It is specially obvious when comparing it to working with a different project, one that hasn't got the attitude.
BTW, there are two papers from ESR that I think are relevant to this discussion.
I hear parenting has similar "reverse deja-vu" moments
(And what a bad timing with Moodle 1.5 branching it has been!)
Exactly what I thought when I saw Sakai as well.
That's an excellent analysis. Would you mind if I "borrowed" the gist of it for part of the paper I am supposed to be delivering to the JISC OSSWatch conference in July? They have asked me to speak about the Moodle community, how it has grown, what it is like, and why Moodle and its community are so successfull (or something like that). And I think you have put your finger on a key point there. A good, dynamic leader caring about the community, and inviting others in to take part, recognising their talent and welcoming in their contributions, while still managing to keep the machine rolling, and guiding it strongly. However, I think Martin *Does* have design originality of his own, as well as recognising it in others
Sean K Beardie
I did a limited review of the community dyunamics and health for the NZVLE assessment of LMSs. It is a bit dated now, but see http://eduforge.org/projects/nzvle/ . If I was to due due diligence for an important project, I would perhaps get hold of a sociologist or anthropologist, and ask her to help me understand the communities around each project and make that a key part of the evaluation. I'd also ask her to draft some hints on how to better engage the community. I'm thinking of someone like Biella Coleman or one of her students.
The homesteading the noosphere and catherdral/bazaar papers are key background. See also my answer to this post:
This could be a great chance to have an open conversation with Sakai, and others, in the open source community.
I notice five other Univ of California schools are partners of Sakai. Are they active? Is there pressure for Humboldt to be a partner? Is anyone actually using
Sakai, or is it just a design that they have been sold on?
My last question still remains...
Are any of these UC universities actually using Sakai with their classes? Or are does their membership mean they are just participating as design collaborators?
I know some of the UCs are using it.
BTW, the California State University system at ~450,000 students is AFAIK the world's largest 4 year system. The University of California is great at many other things, but they have nowhere near our number of students.
Models of Software Development
||"If you built it, they will come!"
||"Come join the fun!"
||"90% under the surface"
||"Keep it in the dark, and feed it lots of ..."
IBM is a big company and they get behind lots of things.
They are also behind Java, their Alphaworks is a really big R&D project.
And Linux, lest we forget the tidal wave that represented IBM's decision
5 or so years ago to make Linux a primary OS, leaving behind AIX.
Now, some read more into IBM's announcement vis-a-vis
Java vs. PHP (and Perl/Python). http://news.com.com/2100-7344_3-5589559.html
is the CNet story, which includes this unattributed quote:
One industry executive who requested not to be named said that IBM's push into PHP and scripting reflects IBM's disillusionment with the Java standardization process and the industry's inability to make Java very easy to use.
"IBM's been so fed up with Java that they've been looking for alternatives for years," the executive said. "They want people to build applications quickly that tap into IBM back-ends...and with Java, it just isn't happening."
I would caution against thinking that IBM has "one master strategy". Nope, I think they have multiple pokers in multiple fires. I think they have learned a lesson
from Microsoft, "let someone else develop cool technology, and then adopt it". This is a fundamental switch for IBM, which has historically run a very large R&D lab and has created a whole slew of technologies, like the punch card, SQL, and SGML.
What's different is MS buys the company with the technology. IBM is playing the open source game and is willing to adopt from that realm.
Probably the better comparision is IBMs relationship with the Apache Foundation. They have put big bucks there, funding the httpd server and Jakarta projects. As SAKAI is aligned with Java and to some extent with the Apache tools, I could see how IBM would view this as continued funding for this general direction of Java.
"Sakai is another open source e-learning system or LMS, it's being used in about 70 schools around the world."
The 70 schools are "involved in Sakai", but not necessarily yet using it. That's
the number of SEPP members. The number using Sakai is currently closer to 10.
Sakai has a lot of different stakeholders to make happy and as such we picked a set of technologies that we think will appeal to the folks (CIO types) who run Enterprise Learning Management systems (yes, that includes Java ) .
I am a big fan of LAMP - we have to separate the technical issues from the "adopter issues".
At some level, we could look at Moodle and Sakai as competitors - but to me that is silly. There are places where folks will want Sakai and would barely consider Moodle and places where folks want Moodle and would barely consider Sakai.
I think that neither projects loses anything by working together. Sakai (if successfull) will pave the way for open source software to be integrated deeply into the enterprise (payroll, etc) parts of the academy. Moodle is not likely to penetrate the "halls of Peoplesoft" the same way. But once the door is opened, people will yearn for the fun, easy lightweight way that Moodle can be expanded.
It is a continuous demand within Sakai to be "as easy to extend as Moodle"
P.S. This is a nice forum tool
As Bryan Williams implied, there has several years of communication between Sakai and the Moodle Partners. This communication with Moodle began with the uPortal project when there was a user question about whether Moodle could be an application within uPortal. Subsequently Bryan and I participated in a discussion with the Illinois Community Colleges in August 2004 ( http://www.immagic.com/eLibrary/ARCHIVES/GENERAL/IMM/S040806F.pdf) where I then represented Sakai.
The Sakai Board has been following the implementation of Moodle and LAMS because they are effective learning platforms and there are opportunities for cooperation. At a Sakai Board meeting late April, the Board asked the University of Hulls Ian Dolphin to contact Moodle representatives. A meeting with Bryan Williams has been scheduled for June 11th in Baltimore (both are giving up their Saturday). Bryan is also trying to schedule a meeting with Martin Dougiamus when he is next in Europe or North America.
An area for cooperation include practical interoperability of learning content. The Sakai Board met earlier this month with textbook publishers (see http://www.immagic.com/eLibrary/ARCHIVES/GENERAL/U_MICH/S050508S.pdf). This initial meeting focused on the benefits of broad cooperation.
Sakai is developing a version using the Web Services Remote Portlet (WSRP) Technology to make Sakai available as an application (portlet) in a portal. Blackboard is also studying this alternative (see http://www.immagic.com/eLibrary/ARCHIVES/GENERAL/U_MICH/I050425F.pdf). Last week we asked the OASIS WSRP Technical Committee chair, Rich Thompson from IBM, for assistance in using WSRP in PHP specifically because of interest in a WSRP version of Moodle. Some work from the U.K.s Joint Information Systems Committee-funded GoGeo project may be useful as well. This information is being shared with the Moodle partners.
Opportunities for cooperation include practical interoperability of learning content, common integration with administrative and library systems, and shared research on best practices for learning and research.
I also need to point out that I am not a member of the Sakai Board, but a staff member of the Sakai Educational Partners Program. I appreciate Bryans complimentary references to our discussions, but wanted to make sure the correct person and position were identified. Both of us are deeply committed to improving higher education and we see this technology as an opportunity. I wish you could join us in our occasional coffee at Borders; cooperation just happens.
Sakai Community Liaison
What is the reasoning behind Sakai's license? From a FOSS point of view, it cuts SAKAI from the community: SAKAI can't use GPL code, can only really use BSD-style licensed code, and pretty much no-one can grab SAKAI's code. Leads to a lot of wheel reinvention / NIH.
The "supply original code + separate patches" clause in the license also means you can't really fork it, should SAKAI's central development line stagnate. Has this been considered?
The intent of our license is to allow anyone to take any portion of our code and use it in any way they see fit and with no constraints on the license of the resulting derivative work. So a GPL project should be able to take Sakai code and use it in any way it likes and keep the GPL license of that software.
Someone *can* fork the code - I sure hope so if the central line stagnates.
There is nothing about patches in the sakai license: http://cvs.sakaiproject.org/licenses/license_1_0.html
If there are some words in the license that lead you to feel that we are trying to put some constraint on reuse, we should clarify it.
thanks for taking the time to answer. I did read the license in detail, and I do find some problems. While I'm not a lawyer, I've taken several courses at Law School on software licensing (undergrad and masters level). Still not a lawyer, but a somewhat informed geek
So a GPL project should be able to take Sakai code and use it in any way it likes and keep the GPL license of that software.
You have provided your code under a given license. I can't redistribute it integrated with a GPL-licensed bit of code, because the two licenses should be able to be combined, and they are not. The ECL has restrictions that are not present in the GPL, and the GPL has a clause that forbids additional restrictions.
This makes the GPL pretty strict, that is certain. But most projects consider it in their best interest to use a GPL-compatible license (BSD, LGPL or GPL), specially because it has been estimated that 80% of the FOSS code out there is covered by the GPL.
This makes it the largest pool of code available. Not all is good, but some bits are really good
Someone can fork the code - I sure hope so if the central line stagnates.
Well, the ECL has two clauses:Notice of any changes or modifications to the Original Work, including the date the changes were made. Any modifications of the Original Work must be distributed in such a manner as to avoid any confusion with the Original Work of the copyright holders.
The first one is relatively harmless, and can be satisfied with a clear changelog. Still, if you fork and fail to maintain the changelog faithfully, you'll be in breach of the license, as you'll be misconstruing the extent and character of the modifications made.
The second one quoted here can be interpreted in a number of ways, but the traditional application of it is that a customized project will be distributed as a tarball containing the original files and a series of patchfiles. This is what happened to Minix, and it frustrated Linus (and others) enough to switch to Linux.
qmail has a similar clause (customizations segregated from the original source code, as patches), and qmail licensing is the source of frequent and colourful flamewars.
Under this interpretation -- widely supported by FOSS tradition, so much so that I don't see any other legally safe interpretation -- someone who wants to fork SAKAI will have the burden of shipping your sourcecode with plus patches, and perhaps a makefile (or ant file) to apply all the patches reliably. If you read the history of the Minix/Linux early days, there is quite a bit of discussion of the non-merits of such requirements.
That is a summary of my licensing concerns looking at SAKAI. I am pretty certain that it does not affect the stakeholders that sit on your board. I come from the side of the the experienced FOSS programmer, and a company built around offering development and services based on FOSS. This is a different kind of stakeholder, the independent developer community you may want to engage.
Is that useful info?
If you are thinking of clarifying to indicate it is GPL-compatible and fork-friendly, you are basically discarding some key clauses of the license, and the end result looks a lot like a BSD license. Might be better to just use a BSD license. Although a GPL license potentially "protects" your community more. But that's a flamewar for another day
I like your term "GPL-compatible and fork-friendly" - my instinct is that those who created this license fully intended to produce a license that was "GPL-compatible and fork-friendly".
I have condensed your issues down to the following questions that I will run around and see if I can get Sakai to answer. Feel free to revise these questions - I tried to word them in such a way as to be very example oriented to lead towards the concerns you express. I tried to make them as "hard" as I could without being mean
FAQ For the Sakai License
In the design of the ECL, does Sakai intend to allow its code to be freely reusable by GPL projects?
Can another organization "fork" the Sakai code and start a new project with the Sakai code as its foundation? If this is done, what are the constraints or rules which will apply to this new activity? What activity/documents/processes on the part of the new project would be seen as adequate to satisfy the "avoid any confusion" clause of the license agreement.
What does the clause "Notice of any changes or modifications to the Original Work, including the date the changes were made." imply? Does this notification have to be sent back to Sakai? What level of detail must be maintained in terms of tracking modifications is necessary? Would it be necessary to document in detail every single line of modification (i.e. maintain a patch list for every modification)? Is simply making the source code of the derived work publicly available sufficient? (i.e. anyone could simply do a "diff" between the two versions of the code to find "modifications").
What would happen if Sakai code were the basis of a derived commercial product with a commercial license? Does the "notice" clause imply that all modifications made by the commercial company must be made public, effectively forcing them to distribute their source code? If modifications are made publically available to satisfy the "notice" clause, what are the license terms w.r.t. those modifications (i.e. could someone take the original Sakai code, apply the commercial company's modifications to produce a new version of the code?
> (i.e. anyone could simply do a "diff" between the two versions
> of the code to find "modifications").
The diff doesn't include dates ;) that's why that part leads us to a detailed changelog.
Bear in mind that if your FAQ terms contradict or cancel terms of your license, the license is what holds. The FAQ is volatile and subject to change. The safe thing is to make your changes/clarifications/etc part of the license, or use a license more fitting the actual intentions.
One thing I realized this morning: you can't reuse code from another ECL project easily. You have to provide a detailed changelog (for that code/library) indicating what changes are "local", and distribute it as original + patches. Ouch.
While the ECL has been approved by OSI, it doesn't have the properties people associate with FOSS. As it stands, it makes it really hard to legally include SAKAI in a linux distro (like redhat, debian, or any of their derivatives).
We discussed your points separately at a Sakai board meeting yesterday afternoon and at an ad hoc Sakai senior developers meeting last night (with beer present).
The general consensus was that folks generally agreed with your analysis of the flaws in our license and that it looked like we likely will have to change our license somehow to fix the mis-match between our collective intent and the words in our license.
I don't know exactly how or when this will be fixed - but we will make sure to fix this before we transition from Sakai "the project" to "Sakai the open source project" in December. I personally would like to see a revised license in our 2.1 release (fallish).
Too bad we're too far to share with the beer part of it
BTW, you mentioned this thread was being discussed in SAKAI-devel? Can you post a link to it? I'm interested in what the reaction of the SAKAI community was. I've been following SAKAI-devel for a while and haven't seen any mention of licensing or other aspects of this Moodle thread.
The developers only have "opinions" - the Sakai Board is what matters - at least where license is concerned.