From http://blog.stackexchange.com/post/518474918/stack-exchange-2-0

When Stack Exchange started, they forked a copy of Stack Overflow, then each team continued to develop and improve their respective platforms in separate development efforts. Currently, the combined Stack Exchange and Stack Overflow teams are in the process of merging the two code bases to take advantage of the best features of the two systems

In hindsight, was this the right decision, or would it have been better to modify Stack Overflow code so that it could do everything that Stack Exchange now can?

Update: I should clarify, I don't mean "should Stack Exchange have been made at all?", I mean "was forking the right way to make Stack Exchange, or should it have been made by modifying the existing code base?"


Given that Stack Exchange 1.0 ended up being something of an experiment, in retrospect it was probably a correct-ish choice to fork the codebase.

In general though I agree forking is almost always a bad idea and should be avoided whenever possible.

But sometimes, you have no options other than bad or worse.

(To put it in context we didn't have much money or manpower, and they looked like very different initatives at the time. Remember SE was one developer when it started.. eventually got to 3.)

  • +1 Even if it may look like a bad decision now, it could have been the best option available at the time. – Jon Seigel May 3 '10 at 2:09
  • Although I wonder if it would've been better to have that one developer working on Stack Overflow's codebase to make it Stack Exchange capable. That ignores the "they looked like very different initatives at the time" part though. – Jon May 25 '10 at 13:13

I think it was inevitable. I mean, Stack Overflow will continue to evolve into a tool that programmers use to ask programming questions, which is far too tapered to be the engine for Stack Exchange, which stands to become a basic tool that can be tailored for various types of Q/A services.

I just finished reading that monster of a post, and I have come out on the other end in support of their efforts to migrate the goals of Stack Exchange to another direction. Their vision, as communicated in that post, seems solid, and hopeful.

There are still a few questions, but it's important to note that the new plans are still very much fresh, and some growing-pains will inevitably follow which will exercise any questions about the new trajectory.


In the podcast with the Stack Exchange team, they mentioned that there were a number of optimizations the Stack Overflow team made for the Stack Overflow codebase -- and those optimizations actually hurt low traffic sites.


In my opinion, forking is almost always the wrong thing to do. At least for technical reasons.

It's copy-and-paste coding on a larger scale. Much better to find your variations and explicitly code them. There exists at least one product that will graphically show which areas of the source base are most likely to change, which might well help in determining how to cope with variation.

  • What's the product? – Jon May 3 '10 at 9:12

No. As a FogBugz user, I frequent the FogBugz SE site and often find myself missing the features that the SO team has put into app since the code lines diverged (clicking on the vote count to see the up/down tally, notifications when someone has @addressed you in a comment, etc.). However, I thought I heard (but I can't remember where) that they are going to bring the code lines closer together once again. This blog post seems to suggest that.


I can see one consideration in favour of it: who the owners of the site are. Jeff & co can roll out changes on S* without worrying about what their customers think of them. Places like mathoverflow have quite different cultures to SO.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .