Here are my quick, shallow thoughts on this release.
I wrote the open source alternative to major vendors (ETS, Pearson, etc.) that competed in the Hewlett Foundation's ASAP competition last year. I started a company around that technology earlier this year (http://lightsidelabs.com/) and have been eagerly awaiting the release of EdX source code.
(as disclaimer, I wrote some preliminary thoughts on the announcement several weeks ago at http://bit.ly/ZJTt8E which are probably useful for gauging my pre-existing bias)
Looking through this codebase, it's roughly the level of machine learning work that I'd expect from a first-year graduate student; it gets the job done but is really only tailored to the very narrow task of essay grading and doesn't offer much extensibility. My guess is that for that narrow task, it does a pretty good job, but in my experience teachers are rarely satisfied with just getting a machine learning-generated score and nothing else. The frontend API is a nice addition and the Django service around it is sure to be beneficial, but it's not really ready for primetime yet.
I'll be eager to see if they continue to develop it or leave this as their open source contribution and continue on to other flashy announcements.
It's great to see the edX release! Good work guys!
However, it's AGPL (Affero GPL) which is really quite an onerous license. As
far as I understand it AGPL requires you to release your changes at the time
you make them rather than at the time you distribute the resulting software.
This will have a big impact on how useful the codebase is to anyone else.
It'll be interesting to see how and which communities develop around it.
The use of the AGPL will mean that it'll be slightly harder to form
companies around edX solutions: there won't be much advantage of
hosting/outsourcing companies over regular on-site consulting companies.
I'd expect these licensing terms to result in most users (i.e.
institutions) having to install and maintain their own solutions on site. As a
result, I'd expect it to be more expensive than other existing open source LMS
systems.
That't a very stranger interpretation of the license. Here is the complete license text minus the GPLv3 itself (which explicitly do not include Remote Network Interaction):
Notwithstanding any other provision of this License,
if you modify the Program, your modified version must
prominently offer all users interacting with it remotely
through a computer network (if your version supports such
interaction) an opportunity to receive the Corresponding
Source of your version by providing access to the
Corresponding Source from a network server at no charge,
through some standard or customary means of facilitating
copying of software.
Is it really that hard to read/interpret? It seems to me as very simple. If you use AGPL software and provide a service to users, and you have modified the software, then those users after accessing your service has a right to access the source code. If you don't modify it, or do not let users interact with the service, then you can happy ignore the (A)GPL part of the license and treat it as GPL.
Yes. that's right. It's "simple". that doesn't mean it's not onerous tho'. It means that every time you put something into production you are required to do all the additional work of formalizing your changes and making sure that they're available.
This significantly blurs the distinction between things that happen inside your organisation and things that happen at the interface of your organisation and the outside world, especially if your organisation is, say, a university and the people "inside" it are your students and you make your LMS based on this code available to them.
The ?GPL software that a universities IT department is currently running is unlikely to be subject to terms such as these and it will cost a lot to put these processes in place and to maintain them. Compared to the GPL, it's quite a hard license to comply with.
What exactly is the complaint. Is it that AGPL require source for web services while GPL do not, or is it that some development practice is to use production trees as the development tree?
Using a production tree as a development tree has many negative aspects. Student will see any compilation error, development bugs, spelling errors, Lorem Ipsum and other "inside" aspect of development. Having the actually code also available at that time might be inconvenient, but it is easily fixed. Don't develop on the production tree. First develop on a development tree and then once done, push to production.
However, if the complaint is that AGPL require that users get source code... well, that's kind of the point of AGPL. It is the singular reason why it was created. If an universities IT department do not want student to have access to the LMS source code, then they need to decide what they least want to do. Spend money on hireing a developer to produce a similar program, spend money on a proprietary program that may or may not do what they want (minus customization), or accept giving student source code so they might read, learn, and maybe even be artistic and improve on. Three things student are sadly rarely allowed to do in universities.
> Compared to the GPL, it's quite a hard license to comply with.
Really? I don't see it.
Compliance should be easy for any site where the source code already resides on the server (e.g. every Ruby on Rails, Node.js, or Python-based site). All you do is you provide an option to download the code that's running on the server. As long as you store secrets outside your source tree (e.g. put HMAC keys into /etc), this should be easy.
One of the coolest things about edX courses, are the interactive tools such as genomics viewer (IGV), circuit builder, also AI auto-grader. Do you think such tools will also be built by the community to be used for building new courses? I guess edX universities would not release them as open-source, since it's one of their competitive advantages, they have also invested a lot of work there.
As someone who contributed a bit to edX last year[1], it seems that they found rake to be a nicer way to encapsulate scripts than, for some reason, shell scripts or something. IIRC it was just setting some environment variables to manage the dev environment. Personally I would have wished that they used Rails instead of Django but this bit of oddity was kind of amusing for me.
[1] As a side note, apparently I'm the #23rd most frequent committer, and I only worked on edX for a couple months, that's pretty cool :)
I wrote the open source alternative to major vendors (ETS, Pearson, etc.) that competed in the Hewlett Foundation's ASAP competition last year. I started a company around that technology earlier this year (http://lightsidelabs.com/) and have been eagerly awaiting the release of EdX source code.
(as disclaimer, I wrote some preliminary thoughts on the announcement several weeks ago at http://bit.ly/ZJTt8E which are probably useful for gauging my pre-existing bias)
Looking through this codebase, it's roughly the level of machine learning work that I'd expect from a first-year graduate student; it gets the job done but is really only tailored to the very narrow task of essay grading and doesn't offer much extensibility. My guess is that for that narrow task, it does a pretty good job, but in my experience teachers are rarely satisfied with just getting a machine learning-generated score and nothing else. The frontend API is a nice addition and the Django service around it is sure to be beneficial, but it's not really ready for primetime yet.
I'll be eager to see if they continue to develop it or leave this as their open source contribution and continue on to other flashy announcements.