Others to keep an eye on: http://area51.stackexchange.com/proposals/3355/mathematics and http://area51.stackexchange.com/proposals/3211/calculus (both justify their existence by contrast to MO!).

The full list of proposals is rather ... interesting!

[1] For those who don't know, a site has to garner a short list of "good example" and "bad example" questions before it can go to The Next Level. The LaTeX proposal has plenty of good ones, but not many bad ones yet.

There is one thing that I should point out that would be a major change if we migrate to SE 2.0: we will be part of the SE network. To ease the frustrations of using a new SE site, I think they're going to start people off with 100 rep if they have a reputable account on another site. This means that we might get a surge of rep 100 users, which could be a bit of a pain, but I don't think it will be a big deal. If people think this is likely to be a problem, please say so.

• Full database dumps for research purposes. (Otherwise it would be hard to accurately measure the broader impact of MO.)
• The PI(s) should be granted administrative privileges without elections and such.
• Other useful stuff...

I nominate Andrew and Yemon more than the rest of the gang because Andrew lives in the cold arctic north, and Yemon lives in jolly old England. That is, it's better if we have moderators in more diverse time-zones.

At the moment, we have Anton, Scott, and David in PST (GMT - 8), Ben Webster in EST (GMT - 5). If we add Yemon and Andrew, we'll have moderators in roughly (GMT + 0) and (GMT + 2). In addition to them, we could use a moderator from Australia GMT+8, somewhere in east asia (GMT + 4-5), and probably somebody in New Zealand.

I think we should be planning for the possibility that StackExchange goes bankrupt.

Fortunately, I don't think we have to worry about that seriously (at least in the short term). Stack Overflow Inc has something to the tune of $6M in venture capital. From what I understand (I have no inside knowledge), they're deliberately putting off deciding exactly what the business model is. They want to make a giant network and then worry about how to monetize it. I actually think this makes sense for them.

It turned out worse than what a sensible pessimist would have imagined, sadly :/

I disagree. The sensible pessimist would have imagined that SE 2.0 migration terms are unfavorable (and cannot be negotiated) and that SE 1.0 will completely disappear. Having the option of leaving things running exactly as they are is a little annoying (I was really looking forward to getting some tasty new features), but overall is pretty decent. Not only that, but there may be some wiggle room since they've said they'll handle things on a case-by-case basis.

@Harry (ideas post): The problem is that they're not doing SE 2.0 out of greed or spite (I think). Given that they're trying to build a huge network, it makes sense for them to impose a lot of control on SE 2.0 sites. If this is correct, then it doesn't make sense for them to go out of their way to code in special exceptions for us. If they can easily accommodate MO as a special case, maybe they will, but it might turn out that it's too much work.

Some negative aspects of migration would be tolerable if absolutely necessary. If SE 2.0 sites don't have any notion of "administrator", it will mostly just be a big pain to update custom javascript, html, or css because I'll have to do it by email. If additionally they insist on "reviewing" and sometimes rejecting such changes, I would be pretty annoyed (I'd probably count that as intolerable). I think moderator elections are a good idea (I've been meaning to post about that ... give me another week). However, some things are absolutely non-negotiable: no ads, full database dumps, and they cannot have the domain. These things don't sound like they should be a huge hassle for them to accommodate. I'll certainly keep everybody here posted when it comes time to negotiate what the terms of migration would be specifically for MO.

I think we should be planning for the possibility that StackExchange goes bankrupt. I have no understanding of where their income stream is going to come from, especially after imposing conditions like this. The strange thing is that we were willing to pay them for this service, but they don't want the money!

1.) Maybe they could make MO a special case where we could do a one-time payment to upgrade to the new SE2.0? This would be optimal, because it would solve fog-creek's problem of incentives, and it allows us to maintain autonomy. Raising the money to do it would be incredibly easy, given the number of generous offers for funding from the users here.

2.) The thing is, this site is essentially community-run, and I can't think of anybody who doesn't want you to have the administrator powers that you currently have. What would be an alright compromise is if they made you and Scott full administrators with backend access (to dumps, the database, the javascript and CSS, etc.) for MO but hosted it themselves. Someone should suggest to fog-creek that a new type of administrator (something like an "overlord") with these priviliges should be created for all SE2.0 sites.

Part of the reason that MO is so good is that we have a very strong administration team that handles both high and low level problems. We should appeal to the fact that administrators can only administer a site effectively if they participate in it. That said, having low-level administration done by fog-creek would be frustrating to them and to us, because they don't understand the issues of the community, and we won't have administrators who can competently deal with problems.

3.) Perhaps we could do something like administrator elections (which Anton and Scott would certainly win), which would mitigate the problem of having SO appoint someone administrator for life.

1. Remain an SE 1.0 site indefinitely at zero cost. There will be no updates to the software except urgent bug fixes.
2. Migrate to the SE 2.0 software under the following conditions: "Sites are owned by Stack Overflow Inc. There is no co-ownership of sites, commercial relationships, or revenue sharing. SE 2.0 sites are run by the community. We will make every effort to accommodate former site owners’ wishes to moderate the early site but no special relationships, like appointing someone Administrator of the site for life, will be considered."

They also say "These issues will all be discussed with site owners and the specifics spelled out on a case-by-case basis." I'll post here if I get any more news. Right now, remaining an SE 1.0 site seems like the only reasonable option since migrating doesn't fulfill any of the requirements I had in mind for migration. It doesn't allow us to retain control of the domain name (in the event that we want to change platform), it doesn't give us access to full database dumps (ditto), it doesn't guarantee that MO remain ad-free (or even have control over ads), and it doesn't give me any control over custom javascript (or css or static pages).

At some point, MathJax may include a control panel that will allow users to select preferences on their own, but that is not available currently.

You may also be able to use different fonts with MML, but I don't really know anything about how that would work.

Unfortunately, I just took a couple of screenshots, undermining my image as a busy man ... I have to learn to delegate these things. Anyway, HTML-CSS:

MML:

The symbols are misaligned in beta 2. What happened?

The fonts changed in beta 2. You must completely replace your beta 1 web fonts installation with the beta 2 web fonts. Both the actual font files and the font metric information in the MathJax code changed in beta 2. If you only update one or the other, they will be out of sync, and characters will appear badly misaligned. Remember to unzip MathJax-webfonts-beta2.zip! Merely replacing the zip file will not update your installation unless you unzip it. This also applies to svn users, who will need to delete the MathJax/fonts directory and unpack the new fonts.zip file. If you get the latest version via svn, the fonts.zip file will take some time to downlaod, as it is approximately 13MB in size, so be patient.

Are there any plans for jsMath to output MathML if possible? That would be close to ideal.

jsMath is no longer being developed. MathJax is the way of the future: it already outputs MathML, and once it is optimized, it should output html+css as fast as jsMath does.

Are there any plans for jsMath to output MathML if possible? That would be close to ideal.

<mtd><mi mathvariant="italic">σ</mi><mo stretchy="false">(</mo><mi>y</mi><mo stretchy="false">−</mo><mi>x</mi><mo stretchy="false">)</mo></mtd>

html+css looks like

<span style="position: absolute; clip: rect(0.16em 1000em 1.526em -0.516em); top: -2.293em; left: 50%; margin-left: -1.731em; "><span class="mtd" id="MathJax-Span-30"><span class="mrow" id="MathJax-Span-31"><span class="mi" id="MathJax-Span-32" style="font-family: MathJax_Math; font-style: italic; ">σ</span><span class="mo" id="MathJax-Span-33" style="font-family: MathJax_Main; ">(</span><span class="mi" id="MathJax-Span-34" style="font-family: MathJax_Math; font-style: italic; ">y</span><span class="mo" id="MathJax-Span-35" style="font-family: MathJax_Main; padding-left: 0.222em; ">−</span><span class="mi" id="MathJax-Span-36" style="font-family: MathJax_Math; font-style: italic; padding-left: 0.222em; ">x</span><span class="mo" id="MathJax-Span-37" style="font-family: MathJax_Main; ">)</span></span></span></span>

LaTeX looks like

$\sigma (y-x)$

do you have some fancy configuration of lynx that can handle javascript?

No. I see LaTeX when I view MO in lynx. That's the best thing to see if you don't have MathML support or javascript (try reading a MathML page in lynx!). I guess I agree that if you can view MathML, that's better than jsMath's html+css display. Incidentally, I discovered today that MathJax can produce MathML output if your browser can handle it and html+css output otherwise (the MathML output is supposedly generated much faster). See the "MathML Output" section near the bottom of the beta 2 documentation. This is slightly suboptimal because if you can handle MathML, but have javascript disabled, you get LaTeX. However, I think this is much better than getting MathML when your browser can't handle it.

But if you looked at SE, you'll see that there's a proposal for a more general mathematical site than MO, so the "riff-raff" will have somewhere to go once that gets off the ground.

Yes, this is the same thing that I was talking about.

@Harry: if you're referring to my comment, then only my students will be allowed access. But if you looked at SE, you'll see that there's a proposal for a more general mathematical site than MO, so the "riff-raff" will have somewhere to go once that gets off the ground.

I'm certainly interested in alternative platforms, but I think calling for MO to switch now is irresponsible.

If you read what I originally wrote, you'll see that I wasn't calling for MO to switch now but to do exactly what you are doing.

I should also "declare an interest" in that I'm interested in this not really for MO but because having used it, I think it would be fantastic to have as a aid for a course. But that would be too small to fit the SE model, and so - quite apart from my ideals on this matter - FOSS is the only way to go.

@Andrea: that's almost exactly what I think except that I see no reason to use javascript. If a browser can't cope with mathml, then if it can take images, send a picture of the maths, and if it can't, send the original source as the text. I think that that's the most accessible way to do it.

@Anton: do you have some fancy configuration of lynx that can handle javascript? When I look at an MO page using Lynx then I just get the LaTeX-ish source. But then I don't actually use Lynx all that much so maybe I haven't set it up correctly.

1) Users without javascript will use mathml

2) Users without mathml but with javascript will use javascript

3) Users with mathml and javascript will use mathml

A similar approach is what is generally used for new HTML5 and CSS3 features, which are not fully supported everywhere.

@Anton: I would bet that if you emailed the people at OSQA and said, "I'm pondering migrating MathOverflow to your system. Here's why I can't do that yet ..." then you'd find that all these problems would silently and softly vanish away.

Actually Scott and I were having that sort of conversation with the people at OSQA several weeks ago, but somehow nothing became of it. I've been in touch with them more recently, and it sounds like things are in better shape now for us to play around with OSQA. I'll keep you posted if there are developments in this direction.

I'm certainly interested in alternative platforms, but I think calling for MO to switch now is irresponsible. There are lots of things that can go wrong, even if we ignore features. None of the alternative platforms have run a site as large as MO; there could be scaling issues. If MO is going to switch, I want to be sure that (1) the transition will be smooth, and (2) there's a good reason to do it. Right now, I believe that neither criterion is satisfied.

I think that Anton has the full data dumps. For some reason, he doesn't want to share it all with us.

I have access to full database dumps. I don't share them because they contain private data (like email addresses, IPs, and exact voting histories). I try to put as much into the sanitized dumps as I can without compromising anybody's privacy. If there's something you think I should include in the public dumps which I'm not including, suggest it on the public dump thread.

All I can say to that is:
lynx www.mathoverflow.net Seriously, javascript is not the same across all browsers and all computers. One would like it to be, of course, but there's no standard for javascript in the same way as there is for MathML. A case comes to mind where the same browser on the same computer produced different results for the same page when viewed as two different doctypes.

I don't follow. The math on MO looks awesome on lynx, but sites using MathML look awful. I have yet to be convinced that the "jsMath model" isn't the right one. MathJax is going to be much more robust and faster than jsMath. I see no reason not to use MathJax regardless of platform.

lynx www.mathoverflow.net

Seriously, javascript is not the same across all browsers and all computers. One would like it to be, of course, but there's no standard for javascript in the same way as there is for MathML. A case comes to mind where the same browser on the same computer produced different results for the same page when viewed as two different doctypes.

@Andrea: I think that Anton has the full data dumps. For some reason, he doesn't want to share it all with us.

@Anton: I would bet that if you emailed the people at OSQA and said, "I'm pondering migrating MathOverflow to your system. Here's why I can't do that yet ..." then you'd find that all these problems would silently and softly vanish away.

It wouldn't come to collecting donations from individual users for a long while.

Especially given the number of very generous offers of funding from people like Pete and the funding from our great benefactor.

@Kevin: It hasn't cost anything yet. The "entry level" SE price plan was $1560/yr, but MO now gets well over 10^6 views per month, so we would be in the $4800/yr plan. If we end up under that plan, money won't be a problem. It wouldn't come to collecting donations from individual users for a long while.

I'm guessing that it would not be hard to raise at least a couple thousand dollars a year by asking for donations from users. I would certainly donate.

At the end of the day, it'd be nice to have somebody whose primary job is to do things like maintain code, optimize server setup, implement clever caching, fix bugs we report, and implement features we request. Starting our own project and hiring somebody like this is way more headache and more expensive than I'd like. Doing it myself is out of the question: that's not what I want my job to be. If the SE team is willing to do it on terms we like, great! I know they're really good at this stuff. If not, there are other people willing to fill that role.

Count me in on the people who are waiting to be told that they can try to divert grant money to MO.

:-)

The most important bit of "terms we like" is that I can still access full dumps and retain control of the domain, so we can pick up and change platform if they go in a direction we don't like. But really I'd rather not change anything at all (in particular, I'd be pretty unhappy about allowing ads), and for all I know they'll be fine with that. I don't think they're out to control MO at all. Anyway, I'll certainly keep y'all posted when I get some real information.

@Harry: They are proposing some way of electing moderators, but my impression is that they haven't thought about the details very carefully yet. When I talked with them on the phone, I explained how important and useful dictatorial and admin powers have been at MO. The guy's reaction was complete agreement. I asked about how they plan to reconcile the clash between "community ownership" and a "benevolent dictatorship" (which I think is probably the best way to run an SE site, with lots of community input), he didn't really give me an answer. He said he'd bring up the issue when they meet to figure out exactly how this sort of thing will work. It could be that he was holding back information, but I really got the impression that they just wanted to let people know as soon as possible that they're not planning on going forward with the old business model and they really haven't figured out how the new system will work.

Very briefly:

• Most of the current Stack Exchange sites will be closed down in 3 months time.
• Active ones are guaranteed 12 months of hosting in their present state (i.e. without further software improvements).
• The current Stack Exchange software is currently being merged with the Stack Overflow software (bringing many enhancements, e.g. comment notifications), and they're referring to this merge as "Stack Exchange 2.0".
• New sites can only be created through a community process, described in the blog post above.
• Existing active sites will be able to migrate to the new software, and it seems likely that exceptions to the usual community rules for 2.0 sites will be allowed.

Before anyone gets into a panic, remember that Fog Creek likes us. Anton was asked for his comments on the new system before it was publicly announced: we're in the loop and can expect special treatment.

It seems that if we can get some exceptions to the usual policy, we'll probably be okay. I think for now the two most important things to ask for are:

• Anton remains our benevolent dictator.
• We continue to have access to complete data dumps.

The current proposal for Stack Exchange 2.0 is that everything will be run by committee, and the public will at best have moderator powers (as opposed to Anton's administrator powers). Hopefully Fog Creek will see sense on this (there's plenty of noise to this effect on meta.SE), but hopefully we can grandfather in an exception. Access to complete data dumps (as opposed to the publicly accessible data dumps we've been providing) should obviously be an inviolable requirement, so that we have the option of switching out to different software. The unfortunate thing here is that if we're exceptional in having access to the database dumps, they may not actually do us much good, as the alternatives (Shapado, OSQA) won't have any reason to track changes in the database format over time, when every other Stack Exchange 2.0 site is siloed.