Super interesting—I did not realize that :). If you guys ever want to pass along feedback on how that went and what you did, please do! <3

We keep meaning to do a writeup on the build process, but so far have been way too busy to get to it. :)

We've always used purple, save for the months of red in the v3 dev work that we then changed just a couple days ago. The purple was pulled directly from http://static.djbooth.net/pics-tracks/asaprocky-peso.jpg :).

Actually it is—it might behave perfectly right now, but the intent is that it is mobile-first and responsive like nearly every other component. If you're running into problems, let us know though via issues. <3

Indeed there will be at least one more RC.

Hey mdo, big thanks for all your work! I've used Bootstrap in one project and will use it in many more.

It's a huge productivity boon and the documentation does a great job of showing you what to do.

Awesome to hear, yo! <3

Especially when combined with companion services such as bootswatch and wrapbootstrap.

Thanks! And no, probably not—the two are most definitely not directly related.

Meh, I'm usually not one for variety :).

The purple space background was designed by an illustrator here at GitHub and I just put it to use. That the page ended up being purple and blue like Bootstrap is kind of just a coincidence. Previously the Enterprise site's background was a custom-made OS X ish space background—lots of blue and gold.

Beyond that I don't see a huge concern of the two looking similar. Bootstrap 3's homepage will be massively different from v2s today if it helps though.

I wrote all the styles for Bootstrap and refactored GitHub's forms and buttons a few months ago for a similar approach. Not 100% the same, but definitely close. All those styles are tested thoroughly within Bootstrap and made it super easy to update and standardize our styles, while at the same time dropping mad duplicate code.

The overall homepage though I think looks nothing like Bootstrap's docs, if that's what you're implying. Also, Bootstrap, and GitHub, was not influenced by Dropbox. We just iterated on that stuff internally in a pull request and shipped when we were happy with it.

I wasn't implying that it looks like Bootstrap's docs, I was saying that it looks influenced by the conventions Bootstrap conforms to, which, makes sense from your first paragraph.

Either way, I don't think it matters. It looks good and clean.

Slipped my mind that you went to Github. Definitely looks a lot like Bootstrap as well. Though if it wasn't inspired by Dropbox, there are nevertheless some strong similarities. Namely the signup form, footer and the call to action for the paid product. I can see developers not understanding what I mean, but surely a designer must!

Not trying to be critical by the way. I'm a huge fan of every company/framework/person etc mentioned here. I'm just really interested in the form, function and messaging of homepages.

Preference, readability, consistency with classes, better spell checking, etc. I always felt we should have done dashes instead, but shipping camelCase meant sticking with it for backward compatibility. With v3 though, we're going with our gut and using dashes.

OK, thanks for the explanation.

It's on our list to check it out because of some of lack of control CSS transitions afford us. Hacks with overflow hidden cause issues, mobile performance is rather spotty, and more. Not a guarantee, but we're considering it.

I don't ever recall saying that, but if I did, I'm happy to have been wrong. Super stoked about the direction we're going.

I am not sure what "mobile first" means, could you please explain what that means for the end-developers?

The only thing to that effect I see right now is that responsive less files will no longer be separate from the core. That will probably mean that I will be forced to support mobile platforms.

Is there more to it?

(Aside, wishing someone would take a deeper look at https://github.com/twitter/bootstrap/issues/4935)

All mobile first means is that instead of scaling CSS down for smaller devices, we start from there and work our way up instead. So far it's smarter defaults, little bit less code, etc.

Why on earth would that mean you'd be forced to support mobile platforms?

That should have read "forced to deal with mobile platforms".

I currently have scenarios where I want the same version on the desktop and mobile. That's trivial because I simply don't include the responsive CSS file.

In 3.0 the media queries are part of the core. So I can't just leave the responsive CSS out. Further, it's mobile-first so things like the navbar would be collapsed by default on a mobile device. I would be forced to negate that to get an uncollapsed navbar on a mobile device (as desktop version).

But the point of mobile-collapsing navigation on mobile devices is for a better user experience. Why would you go out of your way to ignore that right away? And if you really didn't want it, you could always remove those lines of code from your file. Or comment them out so it's there when you revert.