Hi Mike et al.

Perhaps I can add a little additional context and update.

The NEAD data model was very much based on NCEAS' underlying data 
model.  Mike-- for your group, you will definitely need to determine how 
closely your structures and processes map to those at NCEAS and NESCent, 
in order to decide whether you should adopt and revise, or rebuild. As 
you probably are aware, NESCent and NCEAS share a number of similar 
administrative workflows.

When NESCent started up, we gave them full access to the code for our 
fully operational administrative database, and it was initially 
considered whether they could just adopt it offhand.  NCEAS "adminDB" 
was written in Oracle, and served NCEAS quite  well for over a decade.  
I say "served" because recently we customized the NEAD codebase to adapt 
it for NCEAS' administrative purposes. This was due to some persistent 
requests for new features from our administrative staff, and our 
reluctance to invest further into the Oracle solution.  The benefit of 
breaking away to an open-source PostgreSQL implementation (upon which 
NEAD is based) was appealing, even if we weren't too keen on the Spring 
framework.  Anyhow, we are now running a revised version of the NEAD 
codebase, which as I mentioned, was based on the underlying logical 
model found in the original NCEAS Oracle codebase.

The primary purpose of NCEAS' administrative database has been to 
facilitate administrative functions, both logistically in terms of 
arrivals/departures of visitors/residents, and in terms of reporting-- 
metrics for NSF, planning purposes, etc. That is, it is not well 
integrated into the scientific process-- relative to issues like shared 
document repositories, code-versioning systems, bug-tracking systems, 
etc.  I believe the same can be said for NEAD.

The  software engineer  working on the "NCAD" database (NCEAS' 
customization of NEAD) is still doing a few small enhancements and 
bug-squashing on that app.  This code-base could be made fully available 
to you as well...

Cheers,
Mark

On 6/10/11 7:41 AM, Mike Smorul wrote:
> Thanks,
>
> I'd be interested if not in the code, at least any requirements documents/use cases you've identified over the last few years.
>
> -Mike
>
> On 06/09/2011 05:57 PM, Hilmar Lapp wrote:
>> Just FYI, NIMBioS is in the process of resuming their efforts to port NEAD to their environment. If this is something that others want to join, I'd be happy to push for an effort here to put the code up on a public repository, for example github, which would allow others to fork or clone and add their own customizations, for which we could then periodically discuss whether they are worth being brought back into a "master repo".
>>
>> When we started to develop NEAD, that was the one piece of software we thought would for sure never be interesting to anyone else, so there may passwords and stuff inadvertently committed in places when they shouldn't be. So before this goes up on a public repo we better go through the code to weed out such pieces. But we run a private git server too, so perhaps that's a possibility too. Right now it's on a private svn server, and thus not very amenable to sharing some but not all development.
>>
>>      -hilmar
>>
>> On Jun 9, 2011, at 3:43 PM, Mike Smorul wrote:
>>
>>> Hi all,
>>> It looks like we're finally getting things rolling on this end and one of the first thing that pops up is the need for a nead like application to manage administrative tasks bringing in post-docs, personnel, and managing working-groups. With the horror story of trying to port nead to another center still fresh in my mind, what would you all do different if given the opportunity?
>>>
>>> Thanks,
>>> -Mike
>>>


-- 
Mark Schildhauer, Ph.D.              735 State St., Suite 300
Director of Computing, NCEAS         Santa Barbara CA USA 93101
Email: [log in to unmask] 
Phone: 805-892-2509      FAX: 805-892-2510
http://www.nceas.ucsb.edu