What are your requirements (granular) and constraints (abstract and/or granular)? For example: - Define the core need(s) informing the advocacy of the project. - Document the desired outcomes in the abstract, and then with as much granularity as possible. - What class(es) and/or types of documents are you storing? - How many files are you looking to store? - What is the predicted growth of usage (predicting need for scalability)? - What level of meta-data faceting are you looking for? - What are the use cases for data inclusion? - What are the use cases for service consumption? - Identify current statutes and local policies which may guide and/or restrict certain models of implementation and/or use. - What is the breadth of skills directly available to support this project? - What is the depth of skills (how many people with each skill)? - What is the implementation budget? - What is the long term maintenance budget? - Are there opportunities for collaboration and/or partnerships (eg neighboring libraries with a similar need or better, a similar project already in the works? These, and other req-cons can help you to better understand what type of investment should be considered for your project. It can certainly be less feasible for smaller institutions, with less staff, and less wiggle room in budgets to fit a product to the needs. However, going through the process may help you to determine if it feels more like you're trying to cram your needs into a specific product. Forcing a product onto a project in which it just doesn't fit will often lead to predictable failures and resource waste. There may be a realistic possibility that your institution simply doesn't have the means to achieve its core need in this. Detailing your needs, requirements, desires, and constraints though can definitely help you refine the search for solutions, and navigate them with more clarity. It may help you and your colleagues to reinforce the Drupal path, or it may help you craft buy-in for a product/service initially considered "off the table" if it can be demonstrated that that product or service has been successfully implemented by other institutions with very similar needs. Success is oft found in the meta ... Good luck! Joshua Klingbeil - IT Director Wisconsin Valley Library Service *I have learned that when I am able to empty my mind of * * preconception, predisposition, and prejudice... * *... what remains is possibility!* *It's easy to answer "No! And here's why not..." It's empowering to answer "Yes! Now let's figure out how..."* On Thu, May 5, 2016 at 4:15 PM, Kelsey Williamson < [log in to unmask]> wrote: > Hi code4lib, > I was hoping to get some input on this. My small, scrappy institution is > considering using drupal as a repository, primarily via the Biblio module. > > Obviously this is not ideal, but for reasons I won't get into, our tech > environment won't support ePrints or dspace, and hosted services are not an > option either. We do not really have the level of technical expertise > required to support any fedora-based applications, and cannot hire any > additional support. There's a chance existing staff could stretch to get > there, but it would not be a pretty process. > > With all that said, do any red flags come to mind? I looked through both > code4lib and drupal4lib listserv archives and poked around google, but > didn't find much evidence of anyone else using drupal in this way. Seems > suspicious. While my gut tells me it's a bad idea (metadata! standards! > preservation!), I'm having trouble articulating this to my group in a way > that sticks, because using Biblio would be easy. I would appreciate hearing > any other thoughts or opinions on this. > > Thanks! > Kelsey > -- <http://facebook.wvls.org> <http://twitter.wvls.org>