Of the pieces of the puzzle that Arthur listed, some are not very problematic to transfer: - data distribution - code distribution - mailing list maintenance - mailing list hosting I think everybody will agree that tz does not have special demands for those and that there are multiple adequate solutions. (In the interest of full disclosure, I am an officer of the Unicode Consortium, and I think that unicode.org would be a very nice solution.) The interesting part is of course the rest. Before arguing one way or another, I think it would be a profitable exercise to try to characterize how the tz project works. Here is my take; it is based on having followed this list for the past 5 years, but I am not a direct user of tz. I probably have some of the facts wrong, it's definitely not intentional. Let's look at the data maintenance: There are folks in the world who have a vested interest in having tz up-to-date. May be they incorporate it in their product, may be they live in countries with unpredictable DST changes. Together, they track the changes, and over time, they have figured out the best way: find some kind of verifiable source (if possible official) that describes the changes, and provide that to the list; it's even better if there is a patch that goes with it. Arthur collects those, and when he deems the collection large enough or there is something imminent, he proposes a cumulated patch. A little bit of checking, and bingo, we have a new version of tz. I seems to remember that at some point, Paul Eggert also played that role as much as Arthur, but I find less traces in the recent past. I think the main reason this process works (and it works really well, as far as I can tell), is that everybody trusts Arthur and likes what he does: that he double checks the changes to ensure the integrity of the data (or at least publish the proposed changes), that he makes timely releases and that he does not take advantage of anybody. The last point is important: I have the sense that the community really believes that it owns tz, and that tz is nothing more than the community. There is no formal organization that owns it. I have not followed the code maintenance as much, but I have the impression it follows about the same process. The needed changes are less obvious and take a bit more discussion, and the work is a bit more distributed. So what is your perception of how the tz project works, and what aspects do you value (beyond the resulting database)? Eric.