Sakai-12 ContentItem in the Rich Text Editor

The Sakai ContentItem Support in the text editor is now in master and on nightly:

It features a very pretty integration between Sakai and Tsugi using Content Item.

Here is a video demo:

Here is the JIRA:

Here is the test plan:

And if you have five hours you can watch the most boring video in the world – I live streamed much of the work last week to make this work in Sakai:

It is super boring. It is an experiment I am playing with in live coding. I rarely narrate because I am concentrating but you can see what I do. Sometimes I swear – be warned.

Experiment: Live Streaming Coding – SakaiJuly 2017

I am going to do a weird experiment in July. Sakai-12 is code freezing at the end of the month and I am going to put some work into adding some pretty cool features into Sakai-12 in terms of standards compliance. The first bits will be around ContentItem and if I have time I will work on the Outcomes and Membership services.

But one thing I am going to do is live stream my coding efforts. I will announce the streams on Twitter @drchuck.

I also have a PlayList where the recorded streams will be stored. I have a few there already.

The Best Meeting Ever (Sakai 12 Planning)

IMG_6792In the Sakai community we regularly have open meetings of the sakai governance group – the Sakai Project Management Committee (PMC) to plan upcoming releases and strategize about how to best meet user requirements with Sakai. Our most recent open Sakai PMC meeting was June 8, 2017, the day after the end of the Open Apereo 2017 Conference in Philadelphia, PA.

As the current Chair of the Sakai PMC, it was one of the best meetings I have ever participated in my life. I was amazed at how our community has grown and matured since we became part of Apereo in 2012.

While nearly all of the PMC members were present and participating, this was a meeting of the community – not the PMC. Some of the people in the room have over a decade of expertise in Sakai software development, others in the room were customers of Sakai commercial affiliates, others were technical support specialists, we had faculty members, and a number in the room were first-time participants in the meeting.

Neal Caidin, the Sakai Community Coordinator ran the meeting and kept us moving through our topics but made sure to have a very inclusive discussion all along. We had a lot of big issues to cover like:

– When would we code freeze the Sakai 12 release?
– What would be the scope of the Sakai 12 release?
– Where did the NoodleTools contributions fit in the Sakai 12 release?
– Could we remove the legacy Grade Book UI from Sakai 12?
– What were the community hot buttons in terms of “things to fix” before Sakai 12?
– What were the major “holes” that could be filled by Sakai 12?

We had the advantage that we were coming off a great Open Apereo conference and there had been lots of discussion about Sakai in presentations, in BOFs, at Karaoke, and in hallways – so in many ways the post-conference meeting was bringing a lot of threads together to form a plan of action.

We had about four hours to talk so we did not need to rush and could allow lots of people the time they needed to talk. Virtually everyone in the room talked on one or more topics regardless of seniority, role, or experience. The most senior developers spent a lot of time listening and reflecting and helping to add a sense of resource costs / availability to each of the ideas as they moved throughout the room.


Here is some notes from the meeting:

Among many small decisions and ideas, we decided to freeze Sakai 12 at the end of July, and that the old grade book UI would be removed, and that we would try very hard to get the Noodle Partners work into core by Sakai 12 and others.

But what impressed me is how much fun we were having together while discussing these very significant and consequential product decisions that might tie a company product manager in knots. Neal would bring up a topic, the conversation take its time and wander around the room gaining lots of diverse perspectives and wind its way to a decision and then we would move on the the next topic and the pattern would repeat.

All very relaxed and enjoyable – and at the end we had an impressive roadmap for Sakai 12 that was responsive to the community needs and practical in terms of timing and resources. In a way it was the “iron triangle” done properly – together we collectively balanced, time, resources, and features. No one got everything they wanted but we were able to arrive at a balanced plan for the next year.

An Open Invitation

What bothers me as we move into the LMS Vendor Conference season, is how little mainstream commercial vendors actually talk to their users and give the members of the community of adopters and users a seat at the table where final and ultimate decisions are made in regards to the product they are paying 100’s of thousands of dollars for. This is one of the aspects of “Sakai is 100% Open” that makes me most proud.

The commercial LMS vendors are great at throwing parties with an open bar and musical entertainment that runs long into the night. What I would hope customers of these vendors try to do a little bit is see through the parties that are distracting you from the fact that you and your school has very little involvement in the direction of your most important software product on their campuses.

What I would hope is that sometime, that technical support people from a few of these Canvas or Blackboard customers would come to a Sakai meeting and see how it can be done differently and in the open. Just come and sit in the back and listen – or participate if you like. You would be welcome even if you are a Canvas or Blackboard customer. You could come to our Summer Open Apereo meeting or even our Sakai Camp. Sakai Camp is in January and is two days dedicated to the kind of collective meeting to plan for Sakai. You need to register early for Sakai Camp because we have a size limitation. Sakai Camp is more fun because it is 3 days of nothing but Sakai planning – just like the meeting above.

If you come to Sakai Camp you will sit next to and talk the leading lights in the Sakai Community, from our QA leadership, support experts, pedagogy experts, UI/UX experts, end users, and core developers. There is no “hierarchy”, there is no “pecking order”, everyone is encouraged to participate, talk, and share your opinions.

What you would learn from those few days is how a community that cares deeply about each other can work together to produce a world-class learning management system with the best strategy and path towards a truly next-generation learning environment.

Tsugi DB Upgrade Required Upgrade in Master (start of 0.4.x)

Attention Tsugi Production folks.

If you have been following along and doing database upgrades when I told you – my Tsugi commits this morning:

Will not even be noticed. These commits are the first that *depend* on the recent database upgrades being in place.

If you have been ignoring my messages and upgrade from a master a month ago to current master with a git pull, your LTI launches will break because there is now SQL in LTIX in master that depends on:


As well as “deleted” columns in all of the core tables.

If you upgrade and “brick” your Tsugi (which I highly doubt will happen), there are two ways to unbrick a Tsugi:

(1) Go straight to the admin UI

This code specifically tries to limit how much of Tsugi is working (i.e. there are no LTI launches involved in this page) for the admin interface to work. So go to admin, enter the password and do the database upgrade and things should pop back to normal. This is the preferred unbrick trick and works almost all the time.

(2) Log in and drop back to a tag if you are checking out my Tsugi – I made a tag/release with the code that adds all the needed fields, but does not depend on those fields. It can work before or after a database upgrade:

A simple

git checkout 0.3.2

Should do this trick. Launches should work even with a pretty old non-upgraded DB. Log in, upgrade the database, and then re-checkout master and all should be well. You might need a tiny DB upgrade after going back to master – but it does not affect the LTIX runtime.

All my servers,, and my Coursera auto grader are all running master solidly as of an hour ago.

If you get stuck, let me know – I will be watching my email.

Sakai 11.4 released!

This message is from Neal Caidin, Sakai Community Coordinator.

Dear Community,

I’m pleased to announce on behalf of the worldwide community of participants that Sakai 11.4 is released and available for use [1] !

Sakai 11.4 has 144 improvements, mostly bug fixes, [2] including:

18 fixes to the interface (aka Morpheus)
15 fixes for the Lessons tool
14 fixes for Samigo Test and Quiz tool
8 fixes for Assignments tool
7 fixes for the Gradebook tool
6 fixes for Accessibility issues (a11y)

Improvements (features or enhancements) added in this maintenance release include:
Support for Melete Import (LSNBLDR-311)
New property to override the system default and reset tools during navigation (off by default) (SAK-31389)
Improved display option for subset menus (SAK-31824)
Email sent by Messages tool links directly to the specific message sent in Sakai, making it easier to respond to the message (SAK-32240)
Drag and Drop upload enhanced to allow overwriting of existing files (SAK-30924)
Searching on scores improved in Samigo Tests and Quizzes (SAM-3130)

Other areas improved include (in alphabetical order):

Citations Helper
Delegated Access
External Tools (LTI)
PA System
Resources (Content)
Site Archive
Site Info
Sites Admin

Three security issues were fixed in 11.4 (details will be sent shortly to the Sakai Security Announcements list)

[1] Downloading information available at –

2a. Improvements in 11.4

2b. or look directly in the Jira filter –

2c. Github issues (for GradebookNG only)

The path to Tsugi 0.4.x (Roadmap for the next month or so)

I just wanted to let you know about the roadmap for the next month or so that will finish the 0.3.x release and move master to 0.4.0. There will be non-upwards compatible changes in 0.4.0 as the first step will be to do some cleanup after the Tsugi-Koseu split. At this point certain things can be used the old Tsugi way or the new Koseu way – once we go to 0.4.x we will remove the backwards compatibility stuff. More below.

Tasks to finish 0.3.x:

– Add code to the LTIX runtime that handles new data model items (url fields for memberships and outcomes, an user image field, and others). The data fields are mostly there already (please upgrade your database).

This will wrap up and make the file 0.3.x release. Some people will want to switch from master to the 0.3.x branch to avoid or delay the 0.4.x changes.

Major 0.4.x changes:

(1) Remove the vendor folder from

This means that to upgrade Tsugi, you will need to do both a

git pull
composer update

And when tsugi-php or koseu-php are upgraded – you will need to do a

composer update

I know folks think that having vendor in github violates the separation of church and state

I think that after the switch, you will realize it was kind of nice to *only* need to do a git pull and leave the “composer updates” to me.

(2) Make it so that the Koseu tools that organically grew in Tsugi will only exist in Koseu. As an example in my web site, the following URLs all work

Post 0.4.x, only the first (Koseu-style) url will work – the old code will be removed from /tsugi – so the best way to smooth the transition is to switch to the Koseu-style urls. See these files for examples of how to switch:

Comments / questions welcome.

Developing a Tsugi Tool (New Videos)

I use the attendance tool as my “basic” Tsugi tool. I recorded five videos showing how this tool works and showing how you can write a tsugi tool several ways:

– A single PHP file with the controller and view
– A Silex+Twig application
– A JQuery + Handlebars application
– A single page application using JSON and tmpljs

The code is in github:

Each of the variations is in a different permanent branch – cool to be able to switch implementations with a

git checkout handlebars

No Longer Working For Longsight (Belated Post)

This is a bit of a belated post but I figured that I needed to complete the story.

If you recall, I worked as a consultant for Longsight starting March 2014. My employment at Longsight ended July 31, 2016 (last year).

Leaving Longsight was a mutual agreement. I was on the Longsight payroll so that Scott and Sam could support my involvement and travel related to IMS and Sakai. By mid-2016 my MOOC revenue was growing and I had received generous funding from the University of Michigan School of Information (my day job since 2007) that I could use to support my IMS, Sakai, Tsugi, and Apereo travel and involvement. You will notice that I am using this money to travel like crazy, meet my MOOC students, and even giving conference talks about my research on Tsugi and Open Source.

In 2016, Scott, Sam, and I agreed that the money that they were spending on me would best benefit the community if they invested it in expanding their involvement in Sakai – which has worked well in my opinion.

It has been an interesting ride in terms of finding a way to fund my Sakai / IMS related travel over the years. Here is a summary of how it worked:

  • 2002-2006 Chief Architect of the Sakai Project – My travel was funded by the University of Michigan as part of their contribution to the Sakai Project.
  • 2006-2007 Executive Director of the Sakai Foundation – I was a University of Michigan employee seconded to the Foundation and UM continued to fund my travel.
  • 2007-2011 I resigned as Sakai ED and became a faculty member at the UM School of Information. My IMS travel was funded by IMS as a consultant and my Sakai travel (and summer salary) was funded by some of the remaining funds from the Duderstadt Center at UM. By 2011, UM was internally reorganizing and my internal source of funds was going away so my Sakai travel was at risk.
  • 2012-2014 While I continued as a faculty member at UMSI, I was hired as a consultant by Blackboard in 2014 with an agreement that they would support my summer salary, my Sakai involvement and give me a budget to invest in Sakai. I spent about $300K of Blackboard’s money to help finish Sakai 2.9. Late 2013, after a few reorganizations at Blackboard my new supervisor wondered out loud if my talents might be better used to advance internal Blackboard agendae. That was my cue to exit stage left so I had a conversation with Sam on the way back to the airport after the first Apereo Camp in January 2014.
  • 2014-2016 While I continued as a faculty member at UMSI, Sam and Scott at Longsight covered my summer salary and travel to support Sakai and be involved in IMS. During this period IMS paid for a few of my very specific IMS trips. My arrangement at Longsight ended as my MOOC revenue started to grow and the UM School of Information provided me support for my research work that allowed me to participate in IMS and Sakai.
  • 2016-2019 My funding from UM School of Information runs through 2019 – so I will have to figure something else out by then. A portion of the revenue from my MOOCs goes into a research fund that I control – so that might be enough to sustain my involvement post 2019. I am working on five new MOOCs – if those are successful and generate revenue, that might be enough.

I am particularly thankful for the support from Sam and Scott at Longsight. I definitely needed to leave Blackboard in 2014 but really had no options to cover my travel to Sakai. Without their support, I would have found myself able to only do one trip per year and have to pay for it myself. The Sakai community was in an important transition during that period and without Longsight support I would have had to fade into a limited background role.

Over the years, I have found some creative ways to fund my involvement in Sakai and IMS. I completely believe in what we are doing and the powerful contribution that open source makes to evolving educational technology – so it is all worth it.

Why the Founding Schools Left Sakai (Opinion)

Note: This is only my own personal opinion. It does not reflect the opinion of any of the organizations I work for or work with.

I am often asked why the University of Michigan and other schools that founded Sakai and built it for over ten years have left Sakai and moved to Canvas as their primary / enterprise-wide LMS. This is my answer to that question.

It is a very interesting question because while the founding schools no longer are involved in Sakai in leadership roles, Sakai has a healthy open source community and is maintaining its market share quite nicely against Canvas, Blackboard, Moodle and Desire2Learn / BrightSpace. A few schools switch each year but not like the founding schools that all went to Canvas almost in the same year and at the same time. As I see it, there is something different at work between those founding schools and other schools.

I think that it comes down to the notion that in the early and mid-2000s, we *thought* that there was an alternate form of Open Source that we called “Community Source” where the primary participants, authority, funding, and leadership would come from institutions rather than individuals. The leadership would be the CIOs or educational technology directors at universities and they would commit far more resources than a single individual would bring. The form of the contribution would be dedicated staff with travel and other funding support for those staff. This would lead to a more stable resource pool and a more predictable product roadmap and schedule. The logic was that by pooling the contributions, the sum would be greater than its parts and there would be a solid return on investment for each of the contributors.

It seemed like a great idea and a number of projects were founded on this “Community Source” model including Sakai, OpenCast, Open Academic Environment and others. World-class schools like Michigan, Stanford, Berkeley and Cambridge brought significant talent and money and lent their brands to these projects to help them get off the ground. And the model worked for a few years when the focus was getting to a open source “Minimum Viable Product”. The tasks were well defined and large chunks of new code was laid down and progress was very tangible. Filling out the MVP was the shared priority and there were few decisions where different schools wanted to go different ways.

Of course each of these projects imagined that their long term direction was a broader open source community supporting the product so the need for the founding schools to continue to contribute money and resources into the project would be lessened. So at the same time as the project leadership asserted top-down control to build the MVP, there were efforts to bring in the second and third rounds of adopters and contributors to increase the depth and diversity of the community. Initially the value proposition for these later adopters was that these big wealthy schools were doing the hard work and investing lots of resources so new schools could contribute at the margins and dedicate far less resources than the founding schools. In a sense they would “draft” behind the founding schools to conserve their resources.

This community expansion led to a conflict in the priorities between the founding schools and more recent adopters. The recent adopters had needs and the founding schools had needs. The founding schools saw the new entrants as providing resources that should “pay back” the founding schools initial investment. The founding schools felt they should be able to reduce their investments and still maintain control over the project’s priorities. The new schools had little understanding of the costs that the founding schools had already invested and felt that it was not their place to bring resources similar to those already invested by the founding schools.

And even though the projects produced “Minimum Viable Products” after 2-3 years – having a MVP is only the beginning of the need for resources. The founding schools who invested so much in terms of money, people, and institutional commitment in getting to MVP rightly wanted to take a breather. But just at that time, either a major rewrite, or maturing the product feature set, or major performance work was needed to support the ever expanding community of adopters. In any software project the maintenance and improvement of the product always far outstrips the cost of initial development. And that maintenance / improvement is not nearly as “exciting” as building the product in the first place.

So projects find themselves in a sort of stalemate where everyone is waiting for someone else to do something. The founding schools generally begin to feel the pressure to keep investing to improve/finish the product that has become so closely associated with their university brand. The feeling slowly dawns on the founding schools that they can “check out any time they like but they can never leave” – and if they make significant investments to maintain their leadership in the project it will not gain any more fame or glory and barely be appreciated by the schools that are following along on the coat tails of the founding schools.

At the same time, the individuals at these founding schools (like myself) increasingly find the project more interesting because at some point there is real serious software engineering being done. Code is rewritten to be internally cleaner, performance improves, design is improving, small rough details are smoothed out and the adopters and users of the product are becoming increasingly happy. So everyone is enjoying their role in the project except the administrators of the founding schools who are providing significant financial resources. They increasingly feel like their leadership has no payback and they are taken for granted no matter how much money they contribute to the commons. Furthermore they often find themselves in a situation where the community priorities as perceived by the developers in the community (some of whom are paid by the institution) are different than the priorities of the institution footing the bill.

By this time projects are 6-8 years old and many institutions have had some turnover in their leadership / administration. The new administration sees the annual spend on the open source project that their institution founded as a “gift” or “welfare” that has little benefit to them but puts a significant dent in their often shrinking budget. So slowly but surely the founding institutions begin to quietly reduce their commitment to the needs of the many and focus on their own needs. Perhaps they fork the code base and just start customizing it locally to make themselves happy and don’t worry too much about aligning their directions with the shared community code base. Perhaps they stop upgrading to the latest version – one way or another they begin to fade out.

Another aspect of this “fading out” phase is that they stop putting a priority on fixing community-identified bugs in code areas that were originally built by the institution. They fix bugs in “their” code that they find on “their” campus but generally begin to ignore bugs (and proposed fixes or improvements) from the rest of the community. A backlog of unfixed bugs starts to grow and the easiest thing for the institution to do is just fade further away from the project.

The non-founding schools and other community members perhaps would love to fix the bugs in the core code, but out of respect, they wait for the founding schools to do the work. After all the founding school wrote the code and therefore should be expert in the code and why not leave the bug fixing, testing and releases to the school “best suited” for the task.

The administration of the founding schools begin to look for an opportunity to “escape” from the projects without losing too much face. The very project that by this time they have been investing for nearly a decade with millions of dollars from the general fund of the school and with the only future prospect is for the school to look worse over time and lose whatever brand benefit accrued back in the “old days” when the project was young and fresh.

So for schools like Stanford, Michigan and Berkeley, the market buzz about Canvas in 2012 gave them the opportunity to make a “clean break” with the project they founded. In short order, without too much analysis, and without much rationale nearly all the founding schools went to Canvas and did so quickly. They had revolutionized the LMS space by their investment in Sakai, and their investments and brand power had helped build standards like LTI and Common Cartridge, and the Canvas LMS in many ways was the realization of all that investment.

In my mind there is no doubt that moving to Canvas was a perfect exit strategy for the founding Sakai schools. In many ways, Canvas looked a lot like the “Sakai 3 Rewrite” proposed in 2008 that never bore fruit. I have a lot of respect for way that the founding schools found a clever way out while keeping their reputation and legacy largely intact. A reasonable strategy, well timed and executed with Canvas as the primary beneficiary.

But Then What of Sakai?

One might assume that when the forward momentum of a project has slowed to almost a crawl and then the founders leave the project, that it would be time to close up shop, give up and adopt the founding schools new strategy as customers of a company instead of owners of an LMS.

For Sakai, this did not happen. In a sense, the Sakai has been successful because it has re-dedicated itself to real, 100% open source. We focused on greater inclusivity, more balanced leadership, trusting each other as a replacement for top-down authority. Community members made their own choices regarding priorities and when and if they would contributed to shared pools of resources. We accepted the fact that volunteers were truly volunteers and respected each contribution for what it was.

Having a truly open community as core values led to three successful outcomes:

First the non-founder schools around the world had grown to know the technical inner workings of the code as well as the founding schools. They were ready with a queue of bug fixes and performance improvements that they were aching to put into the code base, but the founding schools were blocking them because the founding schools were so “checked out” and did not even want to test other people’s improvements. Once each founding school announced their departure, activity in their areas of the code base greatly increased and it took a very short amount of time until the community was capable of improving, testing and releasing all areas of the code base. And in the post-founder area, there was no “owner” of the code areas so anyone was allowed to participate with large and small improvements and bug fixes.

Second, there were many top-quality schools that had joined Sakai after the founders. Their administration and CIOs felt like they could “do it better” than the founding schools (especially those last few years when the founding schools were quietly reducing their commitment). These schools wanted to take their turn at the helm of Sakai.

Third, the Sakai commercial affiliates such as LongSight and others had become a small but robust economy on their own. The software developers in the Sakai Commercial Affiliates quickly moved into the leading technical roles vacated as the staff of the founding universities were pulled from the project.

A new crop of leading Sakai institutions often decided that instead of hiring and then contributing lots of developers, they would simply write requirements and pay contract developers (often at Sakai Commercial Affiliates) to implement the changes or improvements in Sakai desired by the Sakai schools.

Also the attitude within the community began to change. Instead of maintaining separate forks of the products at the major schools and each company, folks put more energy into improving the community edition of the product. The common shared code became the “gold standard” for the Sakai community and all the investments started moving in the same direction in a very coordinated manner. The amount of benefit to Sakai for each dollar invested has gone up dramatically since the founding schools left. The level at which the remaining Sakai schools were willing to invest was more than the available developers could handle and some fully funded projects waited up to six months before developer resources were available. It was nice to have a “backlog” of projects waiting for developer availability.

The Sakai 10, and 11 releases were really the first “post-founder” releases. And while at times we could have used more resources, the Sakai 11 release was the most technically challenging and important release in Sakai history. With a goal of eliminating the use of iframes to improve accessibility, creating a market-leading responsive UI, and an all-new grade book UI, Sakai 11 was quite a bit of work and took over two years to complete (2014-July-08 – 2016-July-23).

Also moving the source code to github for the Sakai-11 release made it far easier for a larger community of smaller contributors to work together more effectively so there were are now for more “hands” to move Sakai forward.


Nothing is assured but it is quite clear that the departure of the founding schools was a necessary challenge that the Sakai community needed to face sooner or later. There is no question that it was one of several scary “periods” in Sakai community history.

I continue to celebrate the contributions of the founding schools to Sakai, and fully understand the founding schools administration’s need to make a clean break and take a rest from changing the world. Their significant investments in Sakai has led to interoperability standards like IMS LTI and IMS Common Cartridge that have forever changed how we use LMS systems. Their investment made it possible to contemplate the idea of Next Generation Digital Learning Ecosystem (NGDLE).

By relinquishing their leadership in the open source LMS space, our founding schools could free up resources and invest in and lead other interesting educational efforts. The founding schools departure from Sakai leadership also roughly coincided with the rise of the notion of MOOCs in 2011-2012. Stanford, Michigan, MIT and Berkeley are widely seen as some of the strongest contributors in that new space where the focus is building free content rather than building free technology.

No leading university can, will, or should commit to anything forever. These brilliant founding universities should not be expected to invest in a successful project forever to “protect their legacy”. There are only a very few universities in the world that can by force of will invent something that has never been done at scale before like the NSFNet, X-Windows, the Andrew File System, the World-Wide-Web, Mosaic Web Browser, OpenCourseware, Sakai, MOOCs, etc and have those efforts “reach escape velocity” in a way that have a permanent and positive long-term impact on the world. We need to celebrate those rare gifts for what they are and not be sad when those schools take a step back so they can gather themselves and move on to invent the “next big thing”.

Building an “On Ramp” Curriculum for Tech Jobs

This is another one of those blog posts where someone asked me a question and I wrote an essay as my answer. I figured others might find it interesting so I reproduce it here. The question was also asked of my colleague Colleen van Lent so in my response, I talked about our collective approach.

Building an “On Ramp” Curriculum for Tech Jobs

The changing shape of the workplace towards software and web is something the Colleen and I talk about all the time and spend a lot of our time trying to lay the groundwork to prepare people for this new economy through every chance we get.

We are both highly motivated to build educational experiences that are “on-ramps” that build strong foundations for further tech learning.

So far our efforts have been in the following areas:

Teach broad “on-ramp” classes to our UMSI on campus students like

  • SI502 – Intro Python
  • SI539 – Intro Web Design
  • SI664 – Intro Web Development.

We have taken the material from these courses and made Coursera specializations:

We build these three specializations with an eye to making a free curriculum that anyone can master regardless of background and prepare them for an entry level web programming job We hope they would be able to fix bugs, write new code with supervision, and do QA but probably not ready to start their own professional quality software project on their own. Because we focus on “on ramp”, we want to get a wide range of ages and skills to the “starting line” where they can begin to learn more on their own.

These Coursera specializations are very successful and Coursera is doing a great job of providing certifications that the industry is starting to accept as helpful signals for hiring. These certifications have been the primary source of revenue for Coursera. My Python specialization has over 200K completions over the past 2 years. It is one of the most popular and highest revenue specializations on Coursera.

We are also both very committed to free and open access because we feel that a career in web applications is a great way for those with lower financial means to improve their lives. But increasingly Coursera is putting more and more of the content of a specialization behind a subscription based paywall. While Coursera allows for financial aid, some students do not want to apply for aid. Also any financial barrier effectively blocks students in certain countries.

To insure my content remains 100% free, I have built my own web sites to insure that students can access my content and assessments at no charge. Here are my web sites:

  • Python For Everybody –
  • Web Applications For Everybody – – this is roughly what the Coursera specialization will look like in the Fall

These sites are effectively stand-alone MOOC providers using my Tsugi software. The sites track student progress and even award badges as students make progress. Colleen has not built a separate site for her course materials but that is something I would love to see happen to complete the set.

In terms of ascribing “meaning” to credentials, Coursera has spent 100’s of millions of dollars to build brand awareness and has 25M+ students taking courses and probably >100M certificates in LinkedIn. Coursera is five years old and has several TED talks (1, 2). And at this point – with all of that – Coursera certifications are becoming gradually accepted as a moderately reliable signal of suitability for employment.

Coursera certificates are not yet in the same category as Microsoft Certified Professional or Cisco Network Professional certificates. Those are very detailed and very stringent. Ultimately with all that Colleen and I do, if you get all 15 certificates from all three of our specializations – it is like you took 3 community college courses and got at least a “B”. This turns out to be a wonderful way to get students confident enough to play with tech in their current jobs or prepare them to learn more.