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:aha...@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" <bdelacre...@apache.org> wrote: >On Thu, Jan 15, 2015 at 3:24 PM, Rich Bowen <rbo...@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
