How my work might change: does open source require more FTEs to support?

(How my work might change if Notre Dame chose Sakai as its next LMS)

No. No. And no. These are the repeated answers echoing from those who’ve switched from a proprietary LMS (or whatever three letter acronym we choose) to an open source LMS. (And pipe up here if you’re one of them. Tell us your story. Tell us why?).

Then come the caveats. These are worth exploring. Especially in my shoes.

  1. With open source, you can choose how much change you’re willing to invest in.
  2. With open source, you can choose how much ‘give-back’ to the community your institution is tuned for.

About #1. Institutions find it an attractive proposition that open source would enable them to enhance functionality and/or fix bugs on their own schedule and frequency, thus making them more responsive to the Academy’s needs than they were when using a proprietary system.  Can Notre Dame afford to be more responsive to the Academy than we had the option of being with a proprietary LMS?

Now you have options. You can still eat the same cooking everyone else eats. Or, you can cook your own. Cooking your own will take more developer resources. Maybe your Academy wishes the Gradebook you gave them did this ‘n such that-a-way instead? Maybe central IT can tell them they’d be happy to install their departmental version of the Gradebook if they will build it themselves? (You very shortly would be able to tell them that while still using a proprietary LMS, given the adoption of the Learning Tools Interoperability (LTI) standard, but I digress…).

I think Notre Dame at this juncture in time would choose to provide the same level of support and maintenance as previously, and that means that we can bite off maybe adding one to two tool integrations a year. At least initially, we would not necessarily be any more responsive to our Academy’s growing needs.

About #2.

If you choose to cook your own, well then, you might as well make that flavor of the widget available to the entire extended community as well. More home cooked meals = more FTEs. Period. Your choice.

For my part, logic compels me to want an open source solution only if it comes with FTE’s to start Notre Dame’s own CookBook.

5 thoughts on “How my work might change: does open source require more FTEs to support?

  1. Two angles on the FTE costs which are worth considering. Will you be able to recruit and retain the staff? A second calculation to make is your anticipated license increases vs anticipated staff cost increases. The BLS reported that the costs of IT headcount rose over 10% last year and it would appear that we are seeing a major shortage of workers right now on a global basis. If staff costs rise at 10% and the license rises by 5% then then by the power of compound interest one runs into trouble over 3-5 years. Also while a software vendor generally wants to work something out from and economic perspective to retain the account, an IT workers interest is more likely to be to move on. It’s very difficult to keep someone and manage the budget when they have a job offer that is 30% more than their current salary.
    There are alternatives like contracting out hosting or application support and development to a third party, but then you are essentially into the world of commercial software. Theoretically with open source one might have more options, but the size of the overall market has tended to limit things to at most a couple of significant providers in each VLE. Since each of these hosting / service providers end up competing against each other during re-evaluations and rfp scenarios the market pricing tends to level things out across the whole network of providers in the marketplace.

    In summary the staffing vs cost of license issue is complicated. I suspect over time that large numbers of local staff would cost more than licensed software. This may not reflect though the value and benefits to your institution. On the other hand licensing software like Blackboard and leveraging the more stable API and broader developer ecosystem may also let you do even more with Blackboard with the same costs.

  2. John,
    In response to your questions: Of course we can recruit and retain the staff to do whatever we want to do. We can even retool old staff to do new things (including me!). Not only is Notre Dame one of the top 10 higher education places to work (according to this year’s survey by the Chronicle of Higher Ed), our staff has a very high retention rate as compared to other IT organizations, AND our staff contains what I think is an unusually high percentage of Notre Dame graduates (which definitely bumps up the average SAT score even among employees). The other angle, does it really take more FTEs to maintain an open source solution vs a proprietary solution? Hm… I know the answer is no, it does not take more. But then I would amend that and say, “It does not necessarily take more.”

  3. To look more closely at your questions
    Can Notre Dame afford to be more responsive to the Academy than we had the option of being with a proprietary LMS?

    Don’t forget that every change you make has to find its way back to the central source code repository. Open source contributors often underestimate the time required to get a patch reviewed and accepted. As you move up in the community you will be able to fast track your changes, but this takes time and effort to build trust with your fellow developers.

    Also don’t forget the testing impacts. Developers often think oh its just 1 line of code that will just take a second, then they forget the manual and automated testing time, plus doing a rebuild, etc. For example suppose you want to change something complicated in the gradebook. Ideally automated and unit tests can be run in under 30 minutes to do a pretty decent check of the software (assuming the test coverage is there). Figure a little bit of setup and tear down to do a manual test as well. Having done quite a bit of work in software maintenance over the years I can tell you that it takes about 8 hours to fix 1 bug. Sometimes it takes longer, sometimes its faster, but software development stats from IEEE and others do a resource planning in that kind of way.
    So as you consider closing out bugs on a faster pace, or adding enhancements you must consider how many of these you are going to sign up for given the resources you’ve been provided.

    I thought that LSU did a pretty good job looking at this in their Moodle adoption and development plan. They worked to try to set expectations with faculty in advance that even though it was open source they wouldn’t fix every bug or make every enhancement. They set limits and budgets early.

    To return this to my original comment here. The question of staffing levels has to be met with one of service levels. For any software platform setting the right number of staff (with the right skills) to match the desired service level is critical. Understanding this is critical.

  4. John:

    You say: “Don’t forget that every change you make has to find its way back to the central source code repository.” What makes you say this? There is no requirement that the local modifications an institution might make to open source software have to make their way back to any central code repository. What code will travel back leads more to Laura’s question #2, about “give-back” to the community.

    You are right, however, to indicate that levels of effort for code maintenance in general is something to account for with any software project, local or distributed. Every day I watch institutions on both open-source and proprietary paths deal with the maintenance of code for local modifications, integrations, etc. Code maintenance is not just an open source issue.

    Also, your discussion of staffing levels with open source seem to only address one end of the continuum: institutions that engage in open source wholly on their own. At that end, Laura is still right to question if staffing levels are always necessarily higher than they are at institutions on the proprietary path.

    Yet the other end of that continuum is institutions that engage in open source, but rely on commercial providers (like my employer, rSmart) to provide all or most of the technical effort. Institutions on that end don’t need any more staff than they would with proprietary solutions, and they still typically save costs over proprietary solutions because they are not paying license fees.

    In between are institutions that are finding their own comfortable place in the continuum, which can also shift over time as their needs and resources change.

    – Nate

Comments are closed.