Because many end users, just want the software to work, OSS has become a default option in many IT shops because of the clear technological benefits of exposed code and an open distribution license. Pat asks the rather rhetorical question about what level end users and academic administrators should be engaging in dialog about software. Should it principally be about a) the underlying architecture, b) development methodologies, or c) the application itself (functionality)? Pat indicates that the productive part of the conversation, if we want end users to think about software as a tool to get stuff done, is around the functionality of the software, not the technology. That is, does the software function appropriately and meet business needs? When this is the focus, OSS will be viewed, from the end user perspective, the same way as commercial software. The idea is that focusing on functionality, reduces the unfounded technological concerns of many academic end users, allowing the IT department to assess the technological merit of the software, which would include the quality of the code and the ability of the OSS community and associated organizations to do the right thing by the adopting organization based also on the adoptor's capacity. The punch line is about division of labor. The end users should be responsible for knowing, defining, and articulating the functionality requirements, and the IT department is responsible for making them happen automagically, while not confusing the issue with technological concerns about OSS and proprietary software.
- 1032 reads
