6.1 Barriers to the adoption of open source: personal and professional  (Page 8/13)

The value of collaboration and community in open source is a technology issue that provides for higher quality code, rapid development, etc. And, while there is no doubt in the value of community and collaboration for end-users of an application, it is not solely delivered through open source as many commercial providers have excellent user groups.

The above examples of open source development, code exposure and collaboration, are just two examples of how software practices and software applications can be confused. Including open source and community development practices as a benefit in a department’s analysis matrix does not show any real value for a particular software application. These practices are critical factors for highlighting the value of open source as a development process, but not for the specific software that may be under consideration as a packaged feature set.

How many licks does it take to get to the data center of your campus?

All of the above leads to a fundamental question, “What role should end-users play identifying specific software?”

Ok, get ready, here is what’s going to get me in trouble: the answer, “one, two, three… they should not be identifying specific software.” End-users should be developing feature lists, functional requirements, use cases, business rules, workflow, etc. Using these and working with IT staff, potential software candidates can be identified that not only fit the needs of the academic unit, but the technical architecture of the data center. Too often I have been presented with solutions first. Issues revolving around customization (scope of services), support (service level agreements), licensing (total cost of ownership) should be the responsibility of the IT department. This group will best know how to enhance and to integrate software, align support through existing providers or identify new ones, and to assess the total cost of ownership against current resources. If, as an end-user, you and your department are expected to carry out technical assessments, analysis and recommendations, I would suggest your IT department is broken.

Quite honestly, we should not adopt an application simply because it is open source, just as we should not adopt software just because it is commercial supported. I firmly believe that the tenets of open source and community development create better software and therefore assume its presence will grow in adoption. But the responsibility for end-users in software analysis should be in defining functionality requirements and business needs, not in design, development, deployment or support.

Responses

9 Responses to “Barriers to the Adoption of Open Source: Personal and Professional Observations”

1. richardwyles - 18th, 2007 at 7:30 am

Hi Pat, Overall, I concur with much of what you’re saying but for it to work it’s unfortunately reliant on a very smooth service channel between IT and the Faculty and that’s rare in my experience.

In this discussion we must draw out the distinctions between operating systems, web servers and application software that sits upon the network infrastructure. The key difference for me is that we want end-user innovation to drive changes in our VLEs - operating systems etc. is less important for educationalists as that is further back from the interface with learners.