Dorothea, > I think there's an additional issue that may prove even more difficult > to address: the problem of a technical infrastructure widely adopted > by non-technical people. > We should establish that this is actually the norm (as you point out later) and in every industry, not just libraries or archives. Business managers theoretically know what they need, but do not (should not) be expected to write the software to accomplish those goals. > I haven't taken a look at the wiki to be sure, but my gestalt sense is > that a substantial majority of DSpace instances live in academic > libraries and academic-library consortia. As the general run of > academic librarians goes, *I am highly technical*. (Tim Donohue is an > outright anomaly.) > I think you're right that the majority of DSpace adopters right now are in the library or related domains. At least the visible ones. But those institutions are taking various approaches to defining and managing their repository services. Some have one-person-to- do-everything, and some have much more fine-grained support. As one example, at MIT we have a dedicated product manager (not hands-on technical, but quite capable of writing requirements and talking to developers), a dedicated developer, and a sysadmin to look after the production system day-to-day. I wish I had more staff to help out, but this is what we could support for the moment.
The one-person-who-does-it-all model is definitely not going to scale for the sorts of DSpace applications that we're seeing. And if you look at the staffing models for other production systems like ILSes or course management systems no one would expect one person to deal with every aspect of them (including writing the software). These are complex problems that we're just beginning to understand, so expect to see plenty of dead ends and throw-away code before it's over. In other words, *more* investment, not less, at this stage of the game. > As I said, though, I'm > atypical *on the technical high end* of librarianship. I don't think > DSpace has ever come to terms with what that means. It's not end-user > cluelessness that's the problem, as it is with many open-source > packages. It's cluelessness *in the managers of the software*, which > is a different and rather nastier problem. > I will argue strenuously that service managers (or product managers, or program managers, or whatever you prefer to call that role) should *not* be trying to hack the system. They should be, and are, asking for changes that they think will improve the service they run. But who to ask? There are two paths: ask local developers (MIT's case) or ask the DSpace developer community at large. Obviously the former has a better chance of actually getting done, but the latter happens sometimes. For example, your request for an easier, less technical way to configure the system that doesn't require programming skills is very reasonable, but it would take a developer a lot of time to implement that, and it would be to the benefit of the whole community rather than a single institutions (especially the ones that have developers who might do this work, but who don't particularly need it themselves). So how to get that done? You could hire a developer of your own to do it. Or talk your institution (or CIC) into pooling its resources to hire a developer at the Foundation to do the work. etc. > - Since discussion of DSpace development is (understandably!) heavily > tilted toward developers and people with developer-level skills, the > developer community has very little access to and therefore > comprehension of rubber-meets-road requirements and procedures in > real-world library contexts. Also a generalization. Many DSpace developers are confronted daily with local service managers that want stuff. The problem as I see it is that those product roadmaps aren't being widely shared by their service managers (at least not on the DSpace lists) so we don't know where they converge or differ. That's what I'd like to see improved, but I wonder how much agreement there really is between institutions about the right way for repository services to evolve... what you perceive as indifference from developers may actually be indifference from the service managers that decide what those developers should work on... so you may be arguing with the wrong people. > - It has historically been extremely difficult for an individual at my > level of technical savvy or below to be heard by DSpace developers. > So (not to belabor the point) but could you ask Ken and Nolan to give you a dedicated developer for a year? If repository services are a priority for your institution, can you make the case that you need more resources to do what you believe it should? > On the other hand, > open-source developers are notorious for disdain of non-technical > input and the people who provide it, and DSpace has unfortunately not > departed from that pattern. I know most of the DSpace developers, and they all march to some business need or other, usually determined by their managers (or those who sell services to library managers). But as several of the highly-visible developers have pointed out, none of them work for the "DSpace community", they work for a particular university or company or institute and they usually aren't at liberty to work on whatever they like. > - A communication and contribution path for non-technical DSpace > managers. For the sake of everyone's sanity, it should probably be > wholly separate from the developer community, though someone should > have the job of summarizing useful suggestions to one of the developer > lists (and again, I would happily volunteer). Dspace-general is not a > good venue, because too many DSpace managers have abandoned it, or > consider it an announcement list only. > I heartily share your desire for this, and have tried repeatedly to create such a forum without success. So how do we do it, and get people to use it? MacKenzie -- MacKenzie Smith Associate Director for Technology MIT Libraries ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech