Comments on: Fair Enough http://mfeldstein.com/fair-enough/ What We Are Learning About Online Learning...Online Sun, 05 Feb 2012 04:42:18 +0000 hourly 1 By: Desire2Learn Delivers IMS Basic Learning Tools Interoperability (BLTI) Support http://mfeldstein.com/fair-enough/#comment-1643 Desire2Learn Delivers IMS Basic Learning Tools Interoperability (BLTI) Support Fri, 06 Nov 2009 17:41:23 +0000 http://mfeldstein.com/?p=1209#comment-1643 [...] A prototype third-party building block is available for Blackboard through OSCELOT. [...] [...] A prototype third-party building block is available for Blackboard through OSCELOT. [...]

]]> By: Michael Feldstein http://mfeldstein.com/fair-enough/#comment-1642 Michael Feldstein Mon, 02 Nov 2009 23:49:07 +0000 http://mfeldstein.com/?p=1209#comment-1642 You'll get no argument from me about the value of an open source plug-in community. But the rest of your argument does not succeed in defending the position that your employer took in their response to NCCCS. There are plenty of schools using Sakai or Moodle (or linux or apache or drupal or squirrelmail or...) who have "offloaded the overhead of system maintenance...to someone else". It is a fallacy to argue that open source inherently entails assuming the burden of worrying about the platform while proprietary inherently frees the customer from it. You can argue reasonably that a closed source core enterprise platform augmented by an open source plug-in ecosystem is one plausible way to support the needs of schools. But that "one plausible" phrase is the key missing piece that makes your argument here (at least as I interpret it) different from the one your employer has been making, which is the argument with which I have taken issue. The license under which software is released tells you surprisingly little about its quality or the risks inherent in using it. And I do believe it is hypocritical for a company to proclaim that they are all about "open" (without defining what that even means) while telling their customers how risky and scary openness can be. If the openness with which Moodle handles security issues or feature development is a "bad" kind of openness, the burden is on Blackboard to explain exactly what they think the "good" kind of openness is and why they think there is a difference. Until the company does that in a programmatic, plausible and...for lack of a better word...open way, I maintain that it is being hypocritical. You’ll get no argument from me about the value of an open source plug-in community. But the rest of your argument does not succeed in defending the position that your employer took in their response to NCCCS. There are plenty of schools using Sakai or Moodle (or linux or apache or drupal or squirrelmail or…) who have “offloaded the overhead of system maintenance…to someone else”. It is a fallacy to argue that open source inherently entails assuming the burden of worrying about the platform while proprietary inherently frees the customer from it. You can argue reasonably that a closed source core enterprise platform augmented by an open source plug-in ecosystem is one plausible way to support the needs of schools. But that “one plausible” phrase is the key missing piece that makes your argument here (at least as I interpret it) different from the one your employer has been making, which is the argument with which I have taken issue. The license under which software is released tells you surprisingly little about its quality or the risks inherent in using it.

And I do believe it is hypocritical for a company to proclaim that they are all about “open” (without defining what that even means) while telling their customers how risky and scary openness can be. If the openness with which Moodle handles security issues or feature development is a “bad” kind of openness, the burden is on Blackboard to explain exactly what they think the “good” kind of openness is and why they think there is a difference. Until the company does that in a programmatic, plausible and…for lack of a better word…open way, I maintain that it is being hypocritical.

]]> By: George Kroner http://mfeldstein.com/fair-enough/#comment-1641 George Kroner Sat, 31 Oct 2009 16:30:23 +0000 http://mfeldstein.com/?p=1209#comment-1641 Thank you for posting our conversation, Michael. I do think the comparison in the last paragraph is still a little apples & oranges. Developing a plugin for a learning platform (as the OSCELOT community primarily does) is in my mind a significantly different undertaking than developing an entire enterprise learning system from scratch (as for example the Sakai community primarily does). One primary benefit of the plugin approach is that it offloads the overhead of system maintenance (which by most models accounts for 50-75% of the actual cost of development) to someone else - the platform provider. This allows developers instead of focusing on nuts & bolts such as architecture, scalability, & session management to focus their energy on development that has a direct impact on the varying needs of end-users. As an example, consider the Apple iPhone. Does Apple give developers source code access to the iPhone OS? No. Is the iPhone app model a huge success? Yes. Why? Because it turns the phone into a platform that can meet a wide array of user needs. Who owns the overhead of maintaining the core iPhone OS platform? Apple. Is it necessary to rebuild the phone's OS each time a new app is installed? No. Etc. So rather than "opportunistic touting," my opinion is that there are distinct advantages that the plugin model has that are particularly advantageous for smaller open source projects that are more easily scoped, coordinated, built, and maintained. This is the success that I see in the OSCELOT community and one reason why I believe the past two years have seen their community membership double in size year over year. Thank you for posting our conversation, Michael. I do think the comparison in the last paragraph is still a little apples & oranges. Developing a plugin for a learning platform (as the OSCELOT community primarily does) is in my mind a significantly different undertaking than developing an entire enterprise learning system from scratch (as for example the Sakai community primarily does). One primary benefit of the plugin approach is that it offloads the overhead of system maintenance (which by most models accounts for 50-75% of the actual cost of development) to someone else – the platform provider. This allows developers instead of focusing on nuts & bolts such as architecture, scalability, & session management to focus their energy on development that has a direct impact on the varying needs of end-users.

As an example, consider the Apple iPhone. Does Apple give developers source code access to the iPhone OS? No. Is the iPhone app model a huge success? Yes. Why? Because it turns the phone into a platform that can meet a wide array of user needs. Who owns the overhead of maintaining the core iPhone OS platform? Apple. Is it necessary to rebuild the phone’s OS each time a new app is installed? No. Etc. So rather than “opportunistic touting,” my opinion is that there are distinct advantages that the plugin model has that are particularly advantageous for smaller open source projects that are more easily scoped, coordinated, built, and maintained. This is the success that I see in the OSCELOT community and one reason why I believe the past two years have seen their community membership double in size year over year.

]]>