There are many reasons why the ASF requires projects to use its own servers for some items. For example, we couldn't use GitHub until we had built a system that would provide adequate traceability of contributions.
Failure to do that would have meant it was no longer possible to provide the legal umbrella necessary to protect developers and reassure users. Such work takes resources. Add to that the fact there is no guarantee that an external service will still be available, in an appropriate form, tomorrow. There is therefore a risk that projects will be damaged by decisions outside of our control. Replacing such lost services requires resources. Finally, one of the advantages of the ASF is that once you know the core principles of how one project works, you know them for all projects. Our response to these issues is to require projects to use ASF provided services for essential items. What has been unclear is what are these essential items and what can our projects expect from the ASF in the non-essential areas. David Nalley and I, as part of our budget planning, are working on identifying what is considered core and what is not. This will help address the confusion and therefore make it easier for project communities to decide whether they can use external services. What we will not be doing is relaxing any of our rules designed to protect the independence and legal governance of our projects. Sent from my Windows Phone ________________________________ From: Jay Vyas<mailto:jayunit100.apa...@gmail.com> Sent: 1/18/2015 7:37 AM To: dev@community.apache.org<mailto:dev@community.apache.org> Subject: Mailing lists, sites, ... Hi Apache . Every so often we get the question come up: does Apache infra allow/support ____. The answer is sometimes "not yet" and related to the fact that there are 100s of projects that require uniformity at Apache, and it would be chaos of every new project was allowed a new infrastructure. Idea: Now that project infrastructure is easier using things like github and static sites or google groups forums etc.... Maybe the ASF could loosely agree to support some types of "alternative" project tooling, as long all project conversations and decisions and artifacts were centrally archived at Apache?This can easily be done by simply adding an Apache email address to a monitor a particular forum , or github issues notifications or whatever. Benefits of looser grip on community infrastructure: The main benefit of Apache in a post github era is not the storage and mail servers - it's the centralized archiving, community process, and transparent workflow. And those things can be implemented with any technology. So, my general thought is : Apache still can enforce its core principals while loosening some of the more granular rules around infrastructure . Maybe the time is now (or maybe not) to start allowing projects to branch out their tooling ... While still supporting the tried and true mechanisms and not pressuring infra every time someone wants to use some new email alternative or site hosting solution. In any case looking forward to feedback on this from some Apache veterans .
