The problem is that the listserv is not good for brainstorming. 
Expecting any one person to have a fully baked solution (with hosting) 
before posting to the list is not going to happen.  That's why I 
suggested an alternative discussion tool with the vote2promote feature.

I also suggested the mentorship program as a way to get people to give 
back a little bit while also getting guidance.  It's not going to happen 
overnight, but if anyone's interested in either being a mentor or 
mentee, sign up for the RailsBridge pre-conf.  Again, it's not fully 
baked, but those who are interested can discuss it off list to brainstorm.

-Shaun

On 12/4/12 11:38 AM, Jonathan Rochkind wrote:
> While I agree with ross in general about suggesting technical solutions
> without suggesting how they are going to be maintained -- agree very
> strongly -- and would further re-emphasize that it's improtant to
> remember that ALL software installations are "living organisms"
> (Ranganthan represent!), and need ongoing labor not just initial install
> labor....
>
> I don't agree with the conclusion that the _only_ way to do this is with
> a "central organization" or "my organization which has shown
>   commitment through z"
>
> I think it IS possible to run things sustainably with volunteer
> decentralized not-formal-organization labor.
>
> But my experience shows that it _isn't_ likely to work with ONE PERSON
> volunteering.  It IS more likely to work with an actual defined
> collective, which feels collective responsibility for replacing
> individual members when they leave and maintaining it's collective
> persistence.
>
> Is that foolproof? No.  But it doens't make it foolproof to incorporate
> and have a 'central organization' (still need labor, paid or unpaid), or
> to have an existing organization that commits to it (can always change
> their mind, or not fulfill their commitments even without actually
> changing their mind). There are plusses and minuses to both.
>
> I am a firm believer in code4lib's dentralized volunteer
> community-not-organization nature.  I may be becoming a minority, it
> seems like everyone else wants code4lib to be Official?  There are
> plusses and minuses to both.
>
> But either way, I don't think "officiality" is EITHER neccesary NOR
> sufficient to ensure sustainability of tech projects (or anything else).
>
> But i fully agree with rsinger that setting up a new tech project
> _without_ thinking about ongoing sustainability is foolhardy, unless
> it's just a toy you don't mind if it disappears when the originator
> loses interest.
>
> On 12/4/2012 11:08 AM, Ross Singer wrote:
>> Shaun, I think you missed my point.
>>
>> Our Drupal (and per Tom's reply, Wordpress -- ...and I'm going to
>> take a stab in the dark and throw MediaWiki instance into the pile)
>> is, for all intents and purposes, unmaintained because we have no in
>> charge of maintaining it.  Oregon State hosts it, but that's it.
>>
>> Every year, every year, somebody proposes we ditch the diebold-o-tron
>> for "something else" (Drupal modules, mediawiki plugins, OCS, ... and
>> most recently Easy Chair), yet nobody has ever bothered to do
>> anything besides send an email of what we should use instead.
>> Because that requires work and commitment.
>>
>> What I'm saying is, we don't have any central organization, and thus
>> we have no real sustainable way to implement locally hosted services.
>> The Drupal instance, the diebold-o-tron (and maybe Mediawiki) are
>> legacies from when several of us ran a shared server in a colocation
>> facility.  We had skin in the game.  And then our server got hacked
>> because Drupal was unpatched (which sucked) and we realized we
>> probably needed to take this a little more seriously.
>>
>> The problem was, though, when we moved to OSU for our hosting, we
>> lost any power to do anything for ourselves and since we no longer
>> had to (nor could) maintain anything, all impetus to do so was lost.
>>
>> To be clear, when we ran all these services on anvil, that wasn't
>> sustainable either!  We simply don't have the the organization or
>> resources to effectively run this stuff by ourselves.  That's why I'm
>> really not interested in hearing about some x we can run for y if
>> it's not backed up with "and my organization which has shown
>> commitment through z will take on the task of doing all the work on
>> this".
>>
>> -Ross.
>>
>> On Dec 4, 2012, at 10:41 AM, Shaun Ellis <[log in to unmask]>
>> wrote:
>>
>>> Tom, can you post the plugin to Code4Lib's github so we can have a
>>> crack at it?
>>>
>>> Ross, I'm not sure how many folks on this list were aware of the
>>> Drupal upgrade troubles.  Regardless, I don't think it's
>>> constructive to put new ideas on halt until it gets done.  Not
>>> everyone's a Drupal developer, but they could contribute in other
>>> ways.
>>>
>>> -Shaun
>>>
>>> On 12/4/12 10:27 AM, Tom Keays wrote:
>>>> On Tue, Dec 4, 2012 at 9:53 AM, Ross Singer
>>>> <[log in to unmask]> wrote:
>>>>
>>>>> Seriously, folks, if we can't even figure out how to upgrade
>>>>> our Drupal instance to a version that was released this decade,
>>>>> we shouldn't be discussing *new* implementations of *anything*
>>>>> that we have to host ourselves.
>>>>>
>>>>
>>>> Not being one to waste a perfectly good segue...
>>>>
>>>> The Code4Lib Journal runs on WordPress. This was a decision made
>>>> by the editorial board at the time (2007) and by and large it was
>>>> a good one. Over time, one of the board members offered his
>>>> technical expertise to build a few custom plugins that would
>>>> streamline the workflow for publishing the journal. Out of the
>>>> "box", WordPress is designed to publish a string of individual
>>>> articles, but we wanted to publish issues in a more traditional
>>>> model, with all the issues published at one time and arranged in
>>>> the issue is a specific order. We could (and have done) all this
>>>> manually, but having the plugin has been a real boon for us.
>>>>
>>>> The Issue Manager plugin that he wrote provided the mechanism
>>>> for: a) preventing articles from being published prematurely, b)
>>>> identifying and arranging a set of final (pending) articles into
>>>> an issue, and c) publishing that issue at the desired time.
>>>>
>>>> That person is no longer on the Journal editorial board and
>>>> upkeep of the plugin has not been maintained since he left. We're
>>>> now several WordPress releases behind, mainly because we delayed
>>>> upgrading until we could test if doing so would break the
>>>> plugins. We have now tested, and it did. I won't bore you with
>>>> the details, but if we want to continue using the plugin to
>>>> manage our workflow, we need help.
>>>>
>>>> Is there anybody out there with experience writing WordPress
>>>> plugins that would be willing to work with me to diagnose what
>>>> has changed in the WordPress codex that is causing the problems
>>>> and maybe help me understand how to prevent this from happening
>>>> again with future releases?
>>>>
>>>> Thanks, Tom Keays / [log in to unmask]
>>>>
>>>
>>> -- Shaun D. Ellis Digital Library Interface Developer Firestone
>>> Library, Princeton University voice: 609.258.1698 |
>>> [log in to unmask]
>>
>>

-- 
Shaun D. Ellis
Digital Library Interface Developer
Firestone Library, Princeton University
voice: 609.258.1698 | [log in to unmask]