I have started reading Michael Cusumano's "The Business of Software". Its starting premise (software is not like other businesses) might be obvious, but there are very few management books out there that get at some of the subtleties and differences of the software business. Cusumano is SMR Distinguished Professor at MIT's Sloan School of Management.
"In how many businesses does making one copy or one million copies of your product cost about the same? How many businesses have up to 99 percent gross profit margins for their product sales? In how many businesses do many products companies eventually become services or hybrid companies (that is, providing some customization of product features and technical services such as system integration and maintenance), whether they like it or not? In how many businesses is there frequently a ten- or twentyfold difference in productivity between your best employee and your worst one? How many businesses tolerate some 75 to 80 percent of their product-development projects routinely being late and over budget, with 'best practice' considered to be 20 percent on time? How about a company where the people who build products often consider themselves artists rather than scientists or engineers and have the mercurial temperament to go with it? In how many businesses are customers 'locked in' to a particular vendor because of product decisions someone made a decade or two ago that can't easily be reversed?"
After a bitter experience, Scott Leslie notes in EdTechPost that not all open source projects are the same. "Open source is as much about a form of software development practice and social organization as it is about a form of software license (which in the end is simply the precondition for the phenomenon)." How many so-called open source projects have downloadable code, transparent governance, and an active community? Here's Leslie's quote in full:
"I expect there's a lot of folks who will read this and go 'well duh!' Like I said, it feels boneheaded to have to admit to learning this the hard way. I fell for the argument that one could talk about releasing something as open source 'when it was ready' while all the while toiling away in private. And yet, the number of projects I continue to come across, that keep doing exactly this ('Yes ours is an open source project' 'oh, so where can I download the code from' 'oh, it's not ready for release yet') leads me to believe I'm not the only one who's ever been sold this bill of goods. It's important to do this, not just because literally it's the very definition of 'open source', but because it recognizes that fundamentally, 'open source' is as much about a form of software development practice and social organization as it is about a form of software license (which in the end is simply the precondition for the phenomenon). And while you may feel awkward about making your mistakes out in the open, it's easier to work that way if you're already working that way, instead of having to invent a process and openness that wasn't there from the start."
Educause's NLII (National Learning Infrastructure Initiative) has rebranded itself as EDUCAUSE Learning Initiative. We can expect some great things from this new organization. A resource worth checking out is "7 Things You Should Know About...", a series of concise papers on emerging learning practices and technologies. The first two are on Social Bookmarking and Clickers.
"We are pleased to announce that the National Learning Infrastructure Initiative (NLII) has completed its transition to the EDUCAUSE Learning Initiative (ELI).
Under the leadership of EDUCAUSE
Vice President Diana G. Oblinger, the strategic planning team and our
current NLII members have reframed the organization's mission to be advancing learning through IT innovation.
ELI will be focused on learners and successful learning—a unique
emphasis in the teaching and learning with technology community. We
will explore three areas in particular: learners, learning principles and practices, and learning technologies."
Here's the basic starting scenario which can be easily generalized to a variety of use cases:
A researcher at University X (home institution) tries to access a resource at University Y (guest institution). Can we establish an inter-institutional mechanism of trust so that the researcher is seamlessly authenticated using her home credentials and then authorized access to the appropriate resources at the guest site?
Shibboleth software and protocol, which originated as part of Internet
2, solves just this problem. And the InCommon Federation serves as the organizational third-party that mediates the trust.
Join the InComm Federation and may the Force be with you!