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.

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.

Summary

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”.

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.

http://www.npr.org/sections/money/2015/02/05/382664837/map-the-most-common-job-in-every-state

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:

• Python for Everybody (5 courses – Coding, Web services, Scraping, Database)
• Web Design for Everybody (5 courses – HTML, CSS, Responsive, Accessible)
• Coming Soon: Web Applications for Everybody – (5 courses – SQL, PHP, JavaScript, JQuery Handlebars, Silex)

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 – www.py4e.com
• Web Applications For Everybody – www.wa4e.com – 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.

I was asked by a colleague to summarize my thoughts on whether courses should be session based of self-paced on Coursera.

It depends on a few things:

• If there is low enrollment, self-paced works better because the forums feel less “empty” to a new student. If you are starting a new scheduled session every few weeks and there are only a few hundred students – if can be problematic.
• One disadvantage of instructor paced is that there is a temptation to put “events” at the end of classes – special instructor hangouts, etc etc. We initially felt that Coursera Capstone courses needed this special attention for each session. While these events are fun the first time a course is taught and when enrollment is high, after a while they are less fun – especially when they happen every 5-6 weeks and few students show up. We moved toward having events for the “whole specialization” and not just for students currently enrolled – that way when you have live or other special events you get the most benefit for the investment of faculty time. My office hours work perfectly for this. Every 8 or so weeks I meet my students in a bar, make a simple YouTube video and send it around. Reasonable effort – high visibility.
• A key to scheduled is the ability to “roll forward” if a student drops out – Coursera is masterful at this. There is a “session” but if you drop out, and a bit later a new session starts you get an email that says – “Hey – we miss you – a new session is just starting and if you join now your homework results will roll forward to that session so you start part-way done”. Brilliant blend of self-paced and scheduled.

In summary, we went from 100% scheduled 10 week courses 3x per year, to 100% self-paced with five 8-week courses, to this hybrid “scheduled but with easy re-enrollment”. For high enrollment courses like our Python course (1400 new students per week), the semi-scheduled is the best arrangement. For my Internet History low-enrollment course (146 new students per week) – self paced seems to be the right balance.

I am moving towards a non-upwards compatible change in Tsugi/Koseu if you are using it for a web site like www.py4e.com

As I increasingly move towards defining and developing new Tsugi tools and UI with Silex, I am moving functionality like badges.php, login.php, etc into Silex Controllers. The new URLs are sooo pretty and can be mounted at any point in a web hierarchy.

At this moment in the code base, I have duplicated nearly all of the Koseu functionality in the tsugi folder into Silex Controllers and Templates – but I have not yet removed the old files.

The problem is that to use Twig 2.0, I am forced to host in a PHP 7.0 environment. At this point all the legacy files (badges.php, etc) work fine in PHP 5 – but the fancy new “pretty URL” controllers demand PHP 7.

I am going to go for a while with both in the code base – but at some point I will tag the “legacy included” code and then wipe out the legacy code – and at that point Koseu and Tsugi will demand PHP 7.

Like always, when this happens, before anything is deleted, I will snap a 0.3.x tag and then increment the version of tsugi-php, tsugi, and koseu-php to 0.4 and you can switch to a tag and if need be, we can even do a “legacy branch” later if we need to back-port stuff later.

At this moment, my timing is stuck behind getting a PHP 7 environment from UMich – which might be a month or so :(

More later and comments welcome.

We have been teaching the Coursera Python for Everybody specialization for almost two years now and the previous course (Programming for Everybody in Python) started in early 2014. Since 2014, we have touched 1.4 million learners with over 200,000 learners completing at least one course.

We are planning on converting the all five courses in the specialization to Python 3 by June 26, 2017. Things may come up to adjust that date but at this point it looks pretty solid.

This has been about two years of effort with a new textbook, all new slides, a new autograder, and a new web site at www.py4e.com, new lecture recordings, new audio podcasts … you get the picture. Actually uploading it all to Coursera turns out to be the easiest part :)

Also, we have unlocked the fifth course (the capstone) and removed the pre-requisite requirements for the capstone. This allows students to take any of the five classes in the specialization in any order.

Why Python 3?

While there are many in the Python community still using Python 2 and many Python libraries that are Python 2, I think the time has come to teach new programmers Python 3. And if you learn Python 3 and then have to go back a bit to Python 2 in a job situation, think of it as learning a new language. But to me the time has come for teachers to teach Python 3.

Ultimately, Python 3 is a superior language and the language that will be suitable for a very long time. Probably the largest non-negotiable feature is the solid support for Unicode and all character sets. Python cannot be successful if it is only fully functional in Latin/ASCII character sets.

Why Not do Both?

We toyed with this idea for a while, letting Coursera students choose between the versions – but the effort required to keep everything working in both languages would stretch our teaching and support teams too thin. A Coursera course requires more effort than a web site. Five courses are challenging enough – if we supported both languages, we would be supporting 10 courses on Coursera.

Transition (i.e. Yikes my next class is in Python 3!)

We will be switching all of the five classes to Python 3 at the same time. This means that you may have taken one or more courses in Python 2 and then “poof” you are in Python 3 in the next course. If you encounter Python 3 for the first time in Course 2 (Data Structures) or Course 3 (Web Data) – the only difference you’ll find in the content for these courses will be thatprint with parenthesis and raw_input() becomes input().

Python 2.x:

    name = raw_input('Enter your name: ')
    print name

Python 3.x:

    name = input('Enter your name: ')
    print(name)

In Course 3 (Using Python to access web data) you will start to see the changes to the Python 3 urllib module and how we work with Beautiful Soup. We provide you with all new sample code in Python 3.

If your first encounter with Python 3 is in Course 4 (Databases) or the Course 5 (Capstone), you will need to learn about encode() and decode() and how they work with data in databases and across the network. To help with students who took Course 3 or 4 in Python 2, we have added a special lecture (Unicode in Python 3) that covers these topics in Courses 4 and 5.

Where Are the Python 2 Materials?

The Python for Informatics textbook will continue to be available on Amazon. In particular, the Chinese, Spanish and Korean versions of the Python 2 textbook will continue to be available. There are no translations of the Python 3 textbook so far.

The web site www.pythonlearn.com will continue to exist to support the Python 2 book. If there is interest, I can add the Python 2 auto-graders to that web site once the conversion of the Coursera course is complete.

Thanks

There are so many people who helped make the conversion to Python 3 possible. Here are a few that I need to thank: Sue Blumenberg, Elliott Hauser, Tamara Brunnock, Mihaela Mack, Stephen Catto, Alex Hancook, Noni Korf, Jen Vetter, Bryon Maxey, Tim O’Brien, Stephanie Haley, Sabah Baxamoosa, Laura Wandres, and many others.