[SAC] Direction, budgeting, and resources

Committees SAC mailing list
1

All,

It seems OSGeo is going through its bi-annual thrashing about marketing open source software. I admit that I likely caused some of the thrashing with my post to the board [1] about SAC's need for resources that must be considered as well. I put the cart before the horse a little bit, however, and I should have solicited feedback from SAC on what we think our resource needs actually are. I outlined some of the needs that I felt were pressing in the email, but I think we should discuss a bit on where we see SAC going in the next year or three, what our goals for development are, and how we plan to continue to serve OSGeo.

I recognize that being a volunteer system administrator is a rather thankless job. No one usually says much until things go wrong. I would like to thank those who have been putting in effort as part of SAC. That systems work as smoothly as they do is a testament to the quality folks we have working on stuff. I would also like to single out John Graham and TelaScience. Those resources have been extremely valuable to OSGeo and our committee wouldn't be able to accomplish as much as we do without them.

I think we should back up and discuss some of the assertions I made in my email. First, are we at any sort of exhaustion point for volunteer resources? Are SAC tickets not picked up because of an unclear responsibility chain, or because of the labor required to complete tasks. If we were to mix in paid or in-kind resources into SAC for completing some long-standing tasks, do you see it as being a net benefit? Would it hurt SAC's prospects for long-term sustainability?

Does SAC just need hard resources (bandwidth, CPU, disk) moving forward, or should we attempt to procure soft resources (paid or in-kind manpower) as well? Which would be the priority? Am I correct in stating that we need more of either? Are we happy with our current situation, and do you feel that hosting, hardware, and administration are sustainable long term?

I look forward to your feedback.

Howard

[1] [Board] 2009 budget

2

Howard Butler wrote:

I think we should back up and discuss some of the assertions I made in my email. First, are we at any sort of exhaustion point for volunteer resources?

Howard,

I think there are limits with regard to volunteers and making some kinds
of progress. I and others hesitate to step forward to take on new
responsibilities - especially stuff that seems quite technically challenging.

Here I'm thinking of resolving our LDAP problems, and hooking more services
up to it. Also a few other tough problems on osgeo1 that seem hard to solve
partly because we have a small pool of folks with "primary administrator"
access.

I'm also concerned that our approach to backup and recovery on osgeo1
services are lackadasical. We are lucky our ability to recover has not
been tested, but I suspect if they were, we would discover quite a few
holes in our backup strategy.

> Are SAC tickets not picked up because of an unclear

responsibility chain, or because of the labor required to complete tasks.

A bit of both, but also some SAC tickets are basically asking for new
services and there just isn't any volunteer who wants to do it. In
cases like this I wish we had a better process of getting back to the
originator to indicate it is unlikely anything will happen.

> If we were to mix in paid or in-kind resources into SAC for

completing some long-standing tasks, do you see it as being a net benefit? Would it hurt SAC's prospects for long-term sustainability?

I would like to see some paid system administration time available as
long as it isn't too expensive. I would like to see this used to roll
out some new services, review existing security and perhaps lift some
existing routine work off volunteers (I really wouldn't mind someone
else being mailman-man!).

Does SAC just need hard resources (bandwidth, CPU, disk) moving forward, or should we attempt to procure soft resources (paid or in-kind manpower) as well? Which would be the priority? Am I correct in stating that we need more of either? Are we happy with our current situation, and do you feel that hosting, hardware, and administration are sustainable long term?

I think there is a danger in getting hardware resources without a corresponding
plan or manpower to effect a plan.

Things I'd like to see SAC do:

  o Establish more and better resourced buildbot slaves - especially a
    SAC administered windows slave or two.

  o Get more stuff operating off our LDAP server. At least the wiki, but
    also potentially "telascience blade" user accounts, and make it possible
    for services hosted elsewhere to use our LDAP for authentication by
    special arrangement.

  o Segregate the SVN+Trac services from the rest of our services, as they
    seem to be the source of performance problems that are debilitating to
    other services.

  o Drop our contract for osgeo2 as a cost saving measure (currently it is
    mainly hosting wiki.osgeo.org, and some backups).

I think our current hosting, hardware and administration are operating
adequately, but that we are not well prepared for disaster, and we are
having problems improving our services due to lack of hardware, expertise
and manpower.

PS. the mapguide folks are basically setting up their own build farm
because SAC wasn't able to offer them a reasonable home. I think that's
a pity.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent

3

Hi Howard, Frank,

On Tue, Dec 02, 2008 at 02:55:49PM -0500, Frank Warmerdam wrote:

Howard Butler wrote:

I think there are limits with regard to volunteers and making some kinds
of progress. I and others hesitate to step forward to take on new
responsibilities - especially stuff that seems quite technically
challenging.

Here I'm thinking of resolving our LDAP problems, and hooking more services
up to it. Also a few other tough problems on osgeo1 that seem hard to solve
partly because we have a small pool of folks with "primary administrator"
access.

From my point of view we don't have "LDAP problems". We have an Apache

configuration on 'osgeo1' which seems a bit 'inconsistent' to me, which
makes debugging Trac-LDAP authentication stuff much more complicated
than it should be and somehow there's nobody who feels responsible
either to a) make it more consistent or b) grant others the 'clearance'
to move Apache config stuff around. In fact, nobody really dares to
touch the Apache config .... but this is not an LDAP issue - the LDAP
service works perfectly if configured appropriately.

I have to admit that I feel a bit unsatisfied about this - nevertheless
I have not forgotten that I had been the one who promised to take care
for the "LDAP issues" .... I just didn't realize how involved this
attempt would turn out to be.

> If we were to mix in paid or in-kind resources into SAC for
>completing some long-standing tasks, do you see it as being a net
>benefit? Would it hurt SAC's prospects for long-term sustainability?

I would like to see some paid system administration time available as
long as it isn't too expensive. I would like to see this used to roll
out some new services, review existing security and perhaps lift some
existing routine work off volunteers (I really wouldn't mind someone
else being mailman-man!).

I suspect I'd be leaving the group if someone is going to get paid for
the interesting, 'authoritative' stuff while the boring rest is being
left to the volunteers. In the end, this might still be a net win for
the SAC.

Best regards,
  Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

4

Martin Spott wrote:

From my point of view we don't have "LDAP problems". We have an Apache
configuration on 'osgeo1' which seems a bit 'inconsistent' to me, which
makes debugging Trac-LDAP authentication stuff much more complicated
than it should be and somehow there's nobody who feels responsible
either to a) make it more consistent or b) grant others the 'clearance'
to move Apache config stuff around. In fact, nobody really dares to
touch the Apache config .... but this is not an LDAP issue - the LDAP
service works perfectly if configured appropriately.

Martin,

I'll leave the above to Howard - I certainly don't feel safe doing
anything non-trivial to the apache configuration. I would like to
see this resolved (even though I don't really understand the issues).

I have to admit that I feel a bit unsatisfied about this - nevertheless
I have not forgotten that I had been the one who promised to take care
for the "LDAP issues" .... I just didn't realize how involved this
attempt would turn out to be.

If we were to mix in paid or in-kind resources into SAC for
completing some long-standing tasks, do you see it as being a net benefit? Would it hurt SAC's prospects for long-term sustainability?

I would like to see some paid system administration time available as
long as it isn't too expensive. I would like to see this used to roll
out some new services, review existing security and perhaps lift some
existing routine work off volunteers (I really wouldn't mind someone
else being mailman-man!).

I suspect I'd be leaving the group if someone is going to get paid for
the interesting, 'authoritative' stuff while the boring rest is being
left to the volunteers. In the end, this might still be a net win for
the SAC.

OK, well that largely takes any upside out of paid help.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent

5

On Dec 2, 2008, at 2:51 PM, Frank Warmerdam wrote:

Martin Spott wrote:

From my point of view we don't have "LDAP problems". We have an Apache
configuration on 'osgeo1' which seems a bit 'inconsistent' to me, which
makes debugging Trac-LDAP authentication stuff much more complicated
than it should be and somehow there's nobody who feels responsible
either to a) make it more consistent or b) grant others the 'clearance'
to move Apache config stuff around. In fact, nobody really dares to
touch the Apache config .... but this is not an LDAP issue - the LDAP
service works perfectly if configured appropriately.

Martin,

I'll leave the above to Howard - I certainly don't feel safe doing
anything non-trivial to the apache configuration. I would like to
see this resolved (even though I don't really understand the issues).

Let's try to coordinate scheduling weekend downtime where you and I can work through these issues without the expectation that developers can commit things. Any Saturday or Sunday in the next three weeks work for you?

Howard

6

Frank,

On Tue, Dec 02, 2008 at 03:51:26PM -0500, Frank Warmerdam wrote:

Martin Spott wrote:

>I suspect I'd be leaving the group if someone is going to get paid for
>the interesting, 'authoritative' stuff while the boring rest is being
>left to the volunteers. In the end, this might still be a net win for
>the SAC.

OK, well that largely takes any upside out of paid help.

Oh, I really didn't intend to blackmail OSGeo SAC as the situation does
not necessarily have to turn out this way. If the SAC is going to pay
someone for doing admin work and thus entitle him/her to move/merge or
dissect config stuff at their own will, this might still get you
whatever solution quicker than me awaiting at least some sort of
informal approval to break things for a certain transition period.

Cheers,
  Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

7

Martin Spott wrote:

Frank,

On Tue, Dec 02, 2008 at 03:51:26PM -0500, Frank Warmerdam wrote:

Martin Spott wrote:

I suspect I'd be leaving the group if someone is going to get paid for
the interesting, 'authoritative' stuff while the boring rest is being
left to the volunteers. In the end, this might still be a net win for
the SAC.

OK, well that largely takes any upside out of paid help.

Oh, I really didn't intend to blackmail OSGeo SAC as the situation does
not necessarily have to turn out this way. If the SAC is going to pay
someone for doing admin work and thus entitle him/her to move/merge or
dissect config stuff at their own will, this might still get you
whatever solution quicker than me awaiting at least some sort of
informal approval to break things for a certain transition period.

Martin,

I don't see it as blackmail at all. One of the reason we are seeking feedback
is that we don't want to wreck the volunteer dynamic we have already. There
have been a number of things OSGeo and it's projects have avoided trying to
do "with money" specifically to avoid screwing up the volunteer culture which
is so important to us.

I must confess that even I would be tempted to downscale my work level on SAC
stuff if there was someone paid who could take the work though I'd like to
think I'd be applying that time in other aspects of OSGeo.

Best regards.
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent

8

Howard,

On Tue, Dec 02, 2008 at 04:22:50PM -0600, Howard Butler wrote:

On Dec 2, 2008, at 2:51 PM, Frank Warmerdam wrote:

>Martin,
>
>I'll leave the above to Howard - I certainly don't feel safe doing
>anything non-trivial to the apache configuration. I would like to
>see this resolved (even though I don't really understand the issues).

Let's try to coordinate scheduling weekend downtime where you and I

[...] ^^^

Just to ensure I don't get things wrong: Who is meant to be addressed
by the term "you" ?

Cheers,
  Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------