There are many good ideas brought fourth in this discussion.  Let me add some more and continue the conversation.

First, I very much support the idea of a central repository for sharing code even though I have not used a version control system before.  The value that it would would provide to me would be an ability to look at someone else's code and see if it could be used for something that I am working on.  This repository to me would be of most value, if much of the code is shared freely.  Ideally, I see everyone with the UMN ID having read and download rights and project owners deciding who has commit and change rights.  In this sense it would act similar to UMN AD group policies where I am able to see everyone's group policies and learn from how they have been created.

Second point I want to make is that OIT may not be the only organization that may be willing to undertake such a project.  Colleges and units around the university that already have an infrastructure in place may choose to open it up for University wide use.  When the project becomes large enough and the value to the University of demonstrated, OIT may be more willing to centralize the service offering.  This kind of a "grounds up" approach would help clarify the requirements over time as they are gathered from the practice of providing the service.

Lastly, I want to mention Google Code (http://code.google.com/projecthosting/ ) as a possible way to provide this service if Google Code is included with UMN Google Apps offering.  I have used Google Code in the past and have had a good experience.

Tonu

On 5/5/2010 10:35 AM, Christopher Bongaarts wrote:

Christian Dinger wrote:

I couldn't agree more. The ASR web team uses Git (we moved from Subversion a few years ago), but we'd love to see a centralized source code hosting service from OIT. Not only does it make good security sense, but I think it'd also provide a mechanism for inter-departmental collaboration. Just think of things like CAH authentication code and how hard it is sometimes to track down source code and authors to contribute changes/patches.

A central repository doesn't necessarily fix the problem of project abandonment, unfortunately.  At least with the CAH stuff the Wiki page has been useful for bringing a lot of that together.

In fact, Gitorious is open-source and free. I think it would be such an quick and easy win for OIT to set up an instance of Gitorious. Then the we the developers could manage our own repositories and access; it would be minimal work for OIT.

Setting up a new centrally-supported application involves quite a bit more work than that, of course; you have to define the service offering, identify the support/service delivery structure (i.e. who do you call when it breaks?), develop policy and procedures for getting (and perhaps more importantly removing!) access, set and deploy backup strategy, make a disaster recovery plan, documentation/web site, etc.  All this can be done pretty quickly and easily if it's scoped to a single department or workgroup, and you've got one person probably doing most of all of the tasks.  In today's OIT, I count at minimum 6 people involved for the variuos tasks I listed, at least half of whom would not be familiar with the actual service to be provided.

The first step would be to start thinking about what the requirements are for such a service.  Nailing these down is important if you want the system to actually meet your needs.  "Integrates with Dreamweaver, Eclipse, (other IDEs here)" is one I see already.  I'm guessing someone will want to import their existing CVS/SVN/GIT repos, so that would be another one.  Someone should start collecting these and refine them into a solid set.

Then (to answer Aaron's question), take these and provide them to your IT Directors, and ask them to give them to OIT as a recommendation for a service to provide.  This seems to be where we're headed as the "official" interface for IT governance requests.

Craig also mentioned the UMFoundry project, and that the larger concept of having a U-specific developer community (with tools like source control as one piece of it) might be appealing.  I had a discussion a couple years back with Alex about this, and I was skeptical that having a UMN clone of Sourceforge was adding much value.  To his credit, he built it, but it appears to have fallen victim to reorganization and shifting management priorities.  If someone wants to start a similar effort up again, I would encourage you to think about what value you would add over the corresponding "cloud" services available today.

For me personally, I would consider putting the mod_cookieauth{,2} code into a central repository, primarily to get the benefits of a cvsweb-like interface (which I use frequently when tracking down problems in various open-source packages to easily navigate source trees and diff between arbitrary versions without having to checkout a copy locally).  But such a service might not be a good fit for some of our more mission-critical and "private" code.  This would make good requirements-bait: would the service be intended primarily for "shared" code, or also for "private" stuff, and how would access be enforced?