UMFoundry

One very good question recently put to me asks why a campus Open Source software development initiative has not already been done on campus. I have long considered this and I have what I believe is the answer.

It comes down to support and the lack of resources.

The problem with introducing new services at an organization like the University of Minnesota is that we have a strong reputation for delivering high-quality internal support for all of our existing services. This is a good thing, but it ultimately will not scale to the rising tide of high quality software products coming out of the Open Source development sector. When multiple colleges must pool their resources to be able to purchase a license for a given piece of software, they're more likely to work together to build a robust internal support system that includes telephone and e-mail support, on-site support, face-to-face on-site consultation, customization on a contractual basis, basic and advanced training courses, online documentation and knowledge base articles, and everything else that 1-HELP on campus is known for. However, when hundreds of new products begin appearing "in the wild" and getting implemented on campus, people on campus might not be able to get the same level of technical support that they are used to.

We don't offer a UTTC course on Apache Tomcat. But any student, faculty or staff member who wants to could set up a server instance and start providing services through it right now, because it is Open Source and available at no cost. When they run into a secure LDAP configuration question, or want to redirect incoming traffic from port 8080 to 443 and tunnel traffic through Secure Sockets Layer, they won't be able to get advice on that by calling 1-HELP, even though there are people who work for 1-HELP who know the answer and could help them. The only way they could get that advice from someone over the phone is if they accidentally caught that expert while he or she was working a 1-HELP network and telecommunications support shift, or if 1-HELP organized a Tomcat support team, which we are almost certainly not going to do.

People's time, especially the time of support personnel, is scarce and valuable, and a lot of people (especially in my department) are already assigned to a large number of support projects. So, new service offerings are always evaluated by OIT at least partially on the basis of how we could possibly provide support for them. Good products and ideas might never get implemented because we don't have the resources to offer a broad support service for every product that comes through.

Now, it is true that Apache Tomcat has its own robust user community and those people already support themselves and each other through an Open Source Community-based support structure. But when you ask a question to the tomcat-user mailing list at Apache, you can not be certain what quality of response you are going to get. Nor can you be certain that you will find high quality documentation (for the record, Apache Tomcat has great documentation, and their community is very knowledgeable and helpful. I think they're great.) But you won't be able to get someone on the phone or get someone to come over and look at your server configuration. The model that the Apache Software Foundation and other Open Source foundations use for support is based on the assumption that people are distributed throughout the world and can communicate either by e-mail or maybe by chat or telephone if they already know one another.

At the University, we expect and rely on higher quality and more personal technical support than most Open Source projects can provide. We are Minnesota's largest employer, a gigantic community in a very small geographical area (at least this is true on the Twin Cities campus) with enormous amounts of technological experience and a well-trained fleet of support technicians to compliment our high-energy research and development teams. We have more human infrastructure for technological support and R&D than just about any Open Source project in the world. But we can't spread it too thin by trying to officially take on and document hundreds or thousands of Open Source projects.

So, the technology support model we presently use for projects like UMCal or e-mail support does not scale to the onrush of Open Source products becoming available on the market, and the quality of technical support we can expect from any given Open Source product community does not stand up to the expectations of our community. Try calling 1-HELP for Linux desktop support, for an example. This illustrates that the University needs a third solution.

My idea for overcoming the support hurdle is to identify key individuals who already have connections and expertise in the larger global Open Source development community and organize them into an organic, bottom-up community of user groups on campus. We can host user mailing lists that mirror the user mailing lists of these Open Source projects but also provide more localized and immediate contact on campus. Further, we can actively promote the creation of Open Source projects here on campus, because Open Source developers invariably use each other's software and whether they expect to or not get pulled into the gravity of other software communities. So, hosting our own project teams helps create the technically knowledgeable culture of experts on campus who then can provide support to departmental units.

The difficulty in all of this comes back to expectations and the same resource scarcity problems that currently limit the quality of support that Open Source project communities can offer the wider world. Our community of experts on campus might have to volunteer their free time in supporting these Open Source product installations on campus. This could sap their enthusiasm quickly, especially if software development is not something they already do for fun. So, it is not enough to just try to create this community of Open Source product experts without the help of OIT. This community will need OIT's support and vice versa, particularly in developing high-quality self service documentation through tools such as the UMWiki and the new Knowledge Base (http://kb.umn.edu) installation which we plan to roll out in Autumn 2007.

If OIT can help these campus experts capture their knowledge and expertise in tools like the UMWiki and the campus Knowledge Base, and also in the UMJIRA, we can help keep them from burning out on offering support in their free time. And if these experts become familiar with the quality standards of OIT's technology support, then we and the rest of the University community can begin to trust the information we find on their mailing lists and in their knowledge articles, wiki webs and other documentation sources. If our local developers were tied in more closely with the broader global Open Source software development and user community, then our University could get feedback and quality assurance from the wider world, and in return they could come here and read documentation off of UMN web sites for various useful Open Source products.

Consider this--the best documentation in the world on the Oracle Calendar is currently produced by the University of Minnesota. Some of the best documentation on programs like Mozilla Firefox, Thunderbird and Outlook Express is also being produced here. It could be that way with Apache Tomcat, or Jetty or OpenEJB as well, but it will take a hybrid and more organic support model in order to pull it off.

So, the reason that we have not yet been able to fully implement the UMFoundry initiative that I'm talking about here, is that we do not have the community infrastructure in place to "seed the culture", and we don't have the most crucial piece of software infrastructure in place to accept this community.

First, we need to have some advocates or "angels" from the Institute of Technology computer science department, Carlson School of Management MIS program, perhaps CLA's art department, some highly knowledgeable staff members who understand the Open Source community such as Jake Gage, and finally through this larger team we would need to bring students with budding expertise, energy and interest in this area. I consider this the "human intellectual capital" investment. Without a baseline community to promote and seed the initiative, we won't be able to create the local community.

Second, we need a campus SVN and CVS service that is integrated with our central authentication hub, where we can host our project repositories. These repositories need to be integrated with the JIRA, and preferably with monitoring tools such as FishEye. In order to create this, we either need OIT or another department to go to bat and actually build the installation, see to security and set up a management interface to control read / write privileges for each project. We also need to ensure that the projects don't have namespace collisions, so we are back to the support hurdle.

Ultimately, we need a core group of people who are willing to go above and beyond the call of duty to bootstrap this local culture, build the technological infrastructure, integrate the different services, work out the bugs, and recruit talented individuals to join in on the effort. And we need to do it in a way that integrates at some level with the Office of Information Technology, so it must be done in the open. This will need to be a volunteer effort, so a realistic understanding of the costs and rewards for participating need to be communicated to participants.

One of the first things we need is a proof-of-concept, to show that it is possible and that it will work. I've been building that proof-of-concept on my own time, and it is evolving at the rate I would expect.