The haskell.org committee is reaching the end of its first year of operation, so it’s time to look back and see what has been achieved.
The most important work for the year has been trying to get the ownership of haskell.org resources – principally some money from our GSoC participation, and various machines – on a sounder footing.
At the moment, Galois is kindly holding funds on behalf of haskell.org. However, this causes them administrative difficulties and it would also be better for haskell.org for them to be held separately in a vehicle with tax-free status (at least in the US) that can also accept donations.
The main option we have been exploring is joining the Software Freedom Conservancy (http://www.sfconservancy.org). After seeking the community’s consent, we have contacted them to begin the application process. Unfortunately they are currently rather overworked and as they prioritise work for existing projects over accepting new ones, we do not yet know when there will be progress with this.
In the meantime we are also investigating joining an alternative, Software in the Public Interest (http://www.spi-inc.org). Discussions about this option are still ongoing.
The committee would like to thank Jason Dagit who has been helping us to make progress on this issue over the last few months, with the support of his employer Galois.
In response to various requests for subdomains of haskell.org, we have formulated the following policy, now (belatedly!) documented at http://www.haskell.org/haskellwiki/Haskell.org_domain#Policy_on_adding_new_subdomains
Subdomains should be used for services rather than content.
Content should be normally be hosted at subpaths of http://www.haskell.org
In contrast, during the year, we did add revdeps.hackage.haskell.org for a hackage reverse-dependency lookup service, and of course hackage.haskell.org already exists.
Clearly the line between services and content, and indeed the precise definitions of each, is something of a grey area, and we are certainly happy to be flexible particularly if there are technical or other reasons for doing things one way. Our overall goal is to minimise unnecessary proliferation of subdomains and to try to keep the haskell.org domain reasonably well organised, while still helping people do useful things with it.
Move of www.haskell.org to a new dedicated host
For many years, www.haskell.org was generously hosted by Paul Hudak at Yale. This was becoming increasingly expensive for him so in late 2010 we moved to a new dedicated host (lambda.haskell.org). At the same time we put in place a policy that lambda would host only “meta” community resources, thus limiting the number of people who need to have accounts on it. For some time before this new project content had been created on community.haskell.org anyway, and this move gave us the opportunity to move “legacy” sites such as gtk2hs over to community. In addition, community.haskell.org is now also a VM running on the same machine.
The committee as a whole’s involvement in this was only to approve the change – the sysadmin team did all the actual work.
The haskell.org infrastructure as a whole is still in a rather tenuous state. While the extreme unreliability we saw for a while has improved with the reorganisation , the level of sysadmin resource/involvement is still inadequate. The committee is open to ideas on how to improve the situation.
Unfortunately we can’t provide a full statement of haskell.org’s accounts with this report; we are doing our best to track down the necessary information and will produce them as soon as possible. Better control and visibility of our finances and assets is of course one of the benefits we are seeking by affiliating with SFC or SPI.