community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ross Gardler (MS OPEN TECH)" <Ross.Gard...@microsoft.com>
Subject RE: projects.apache.org overhaul proposal
Date Thu, 15 Jan 2015 17:46:47 GMT
Where are you seeing "discouragement of pilot projects"? Any volunteer can step up and deliver
any pilot for the foundation on a voluntary basis. We are set up to do that.

However, if a service stood up by a volunteer becomes a core part of the ASF then that must
be maintained in an ongoing basis. This has budget and resource constraints. Yes we have volunteers,
but we don't give volunteers pagers, we have a paid team of contractors who take that kind
of responsibility. We can't tell volunteers what to do with their time and we expect our contractors
to make decisions that mean they can deliver on our expectations as expressed by VP Infra.

It would be wrong of the foundation to say "sure go implement that wonderful sounding solution"
without also saying "but be aware there is no guarantee that the foundation would actually
use it". I'm pretty sure any volunteer would feel abused by such an approach.

Nobody has said to Daniel "go get infra backing" because his proposal does not change current
core processes (it pulls data from those processes but does not write to that data). Furthermore
the results of his work, while beneficial to the foundation, are not core to the foundation.
If projects.apache.org were down it would be an inconvenience. Waiting for a volunteer to
fix it would not be a concern. However, if the system we use for creating and managing core
data (as per the OfBiz proposal) were down it would be a significant problem and we would
not want to wait for volunteers. Because of this the foundation would look to VP Infra to
provide an SLA for that service and VP Infra would say "fine, but for that SLA it will cost
$x". 

In a perfect world VP Infra will be able to mobilize volunteers and would not draw on that
budget line, but we have to plan for the circumstances in which volunteers are not able to
react in a timely way. Add to this that historically we know that volunteers often disappear
(as is their right).

In short, the foundation cannot rely on volunteers for core services. What we can, and should,
do is rely on volunteers to reduce the costs of those core services. 

With 170+ projects to consider it's arguably the responsibility of those volunteers to actively
seek out ways in which they can help reduce those costs (this is one of my own criteria for
member candidates).
 
Pierre, for his part, is now following up with the appropriate people (thanks Pierre).

Ross

-----Original Message-----
From: Alex Harui [mailto:aharui@adobe.com] 
Sent: Thursday, January 15, 2015 9:22 AM
To: dev
Subject: Re: projects.apache.org overhaul proposal



On 1/15/15, 6:35 AM, "Bertrand Delacretaz" <bdelacretaz@apache.org> wrote:

>On Thu, Jan 15, 2015 at 3:24 PM, Rich Bowen <rbowen@rcbowen.com> wrote:
>> ...*historically*, when this kind of thing has happened (project 
>>implements,  thing becomes critical), gradually it becomes the 
>>responsibility of Infra,  not of the project, to do ongoing 
>>maintenance....
>
>Yes, this is why I'm reluctant to encourage any initiative that 
>requires our infrastructure team to support new tools. And I suspect 
>infra shares that reluctance ;-)
>
>That being said, it's always a question of benefits vs. costs - but if 
>a simple thing using technologies that every web developer is supposed 
>to know works the choice is a no-brainer for me.

IMO, that reluctance is the challenge faced by any ASF project that isn’t yet on the list
of what everyone is “supposed to know”.  AIUI, Infra is also staffed by volunteers so
project folks can volunteer to be Infra for their project’s usage at the ASF.  And if it
isn’t “easy” for non-project Infra folks to grok how the project’s technology works,
that is just another challenge for the project.  One would suspect that they’ll face the
same battle acquiring new customers anyway.

I’d guess that most ASF projects are not yet a standard and want to be the new standard.
 Getting that first testimonial is often key to becoming the new standard.  It seems wrong
for the ASF to discourage establishment of pilot implementations until the project establishes
a track record on some other set of customers.  IMO, the ability to get an Azure VM is game
changing in this regard.  The project’s committers can take full responsibility for the
pilot program.  All Infra might need to do is establish one-way or two-way database or file
mirrors so the pilot can’t mess up what works until it is deemed ready.  I’d bet that
most of a project’s customers would do that anyway.

Infra should be encouraged to learn new things if the ROI is established by the pilot program
and includes the cost of training non-project Infra folks, and those folks should ask for
support like any other customer on that project’s list, and if they don’t get timely and
helpful support, reject the product just like any other customer would.


In summary, the ASF should be a slightly more willing customer for any of its projects.  Azure
VM’s seem to provide a way to do that without adding more load to Infra.

-Alex

Mime
View raw message