Definitely getting a bit off topic, but... :) Matthew Porter, who works for Contegix, recently wrote an article that I think is very relevant:
http://www.porterhome.com/blog/matthew/2005/11/15/1132088805733.html Contegix has tried to address these "single points of failure" by providing a broad team of experts to manage the servers -- all of whom are experts at Java and these products. Even still, I think for open source organizations to feel "truly free", hosting solutions like java.net, SourceForge, or even Contegix need to offer things like nightly backups of not just source code, but _all_ the data (jira, wiki, etc). Organizations like Apache could then download those backups and have a much better contingency plan. On 12/1/05, Martin Cooper <[EMAIL PROTECTED]> wrote: > On 12/1/05, Ted Husted <[EMAIL PROTECTED]> wrote: > > > > On 11/30/05, Martin Cooper <[EMAIL PROTECTED]> wrote: > > > I am very much against taking ASF content off-site, as it were. We have > > a > > > perfectly good wiki, and that's where our content should be. I know > > there > > > are a bunch of Confluence fans out there, and maybe it's a better > > product in > > > some ways. But the ASF has standardised on a wiki, and we shouldabide by > > > that. (Was anyone hosting ASF code on an SVN server outside the > > foundation, > > > before we moved to CVS, just because it was better? I don't think so.) > > > > The ASF doesn't "standardize" on this type of tool. Them that do the > > work make the decisions. What tools a community uses and how we use > > them is up to the individual PMCs. What the ASF cares about is whether > > the project's development community uses the tools to collaborate. > > > > Point in fact, the only reason we have a JIRA instance now is because > > some projects started using their own instance off site. Because > > projects were voting with their feet, we were able to find volunteers > > to setup the JIRA instance. Now, people didn't push for our own JIRA > > instance because it was "wrong" to have an issue tracker elsewhere, we > > pushed for it because if some projects wanted to use JIRA, then it > > follows that others would want to use it too. Looking at our JIRA > > instance now, I'm thinking that was a good call :) > > > I'm not so sure. Much as I like JIRA, the ASF JIRA installation is > vulnerable. It is effectively supported only by Jeff Turner, who works for > Atlassian. We are dependent on him - and the fact that he works for > Atlassian - for fixes, maintenance, and enhancements to JIRA itself. If he > disappears, we are in trouble. The same concern has been expressed about > adding a Confluence installation at the ASF. > > For security and legal reasons, the ASF has decided that the > > foundation must have all of our *source code* in our repository on our > > machines, and the ASF does want us to retain essential services, like > > the mailing lists and primary web site, on ASF hardware. But secondary > > services, like issue trackers and wikis, can be kept anywhere a > > project finds convenient. > > > If you ask on infra@, I don't think you'll get agreement with that last > statement. > > -- > Martin Cooper > > > When security and legal issues do not trump, what works for the > > volunteers, works for the ASF. Volunteers are the only ASF resource > > that matters. > > > > If the WebWorks merger goes through, another aspect will be "eating > > our own dog food". JIRA, Confluence, and Jive all use WebWork, and the > > ASF *does* prefer that we use our own software when we can. If WebWork > > is going to be our software, then, all things remaining equal, we > > should give first preference to WebWork products. > > > > Of course, personally, I don't believe all things are equal. By > > comparison, I find moin-moin painful to use. Being only human, I will > > contribute fewer hours to working on a moin-moin wiki then I will a > > Confluence wiki. I'm in the web application business, and I enjoy > > using well-designed web applications, like JIRA, Confluence, and Jive. > > Like most volunteers, I prefer to "volunteer with pleasure". > > > > -Ted. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
