Love the idea for the tool, and happy to see it support Javascript. Some feedback:

- Let open-source projects still live under an account, instead of being weirdly separated. Just oauth with Github and automatically lint all of my repos. I definitely wouldn't mind getting an email for all of them. You're making way more work for yourself by splitting open-source vs. private, when I don't think you gain much. Companies will still have to use the private system. Look at Travis for a better example of how to do this. This is critical to me using the product, I don't want to have to remember the link to these things every time.

- Call it "open-source" not "OSS". Unnecessary abbreviations are confusing. I don't ever refer to it as "OSS", but I'm sure the people who do still understand "open-source".

- The other benefit to letting me actually have an account for open-source things is that I don't have to see the annoying marketing bar all the time when visiting my own repo.

- Even though that solves the marketing bar, get rid of the marketing bar. It's by far my most hated "feature" of most sites, and I would feel pretty comfortable saying that since your target audience is developers most of them probably aren't fans.

- The other benefit is that the ignoring patterns don't need to be migrated over, they're just there. (You'll see this pattern a lot, because separating open-source out is a bad abstraction in your app's design, so it will lead to tons of other random problems and extra work. I'm literally doing this right now for Segment.io -- moving from "projects" that exist by themselves to "users" and "organizations" that contain them.)

- Have an option not to lint. The linter options are really strict, I use a very lax version of JSHint in Sublime, but I don't use .jshintrc because I don't want extra bloat files in my repos.

- It seems like every time I want to add a new open-source repo I have to navigate to the pricing page a click a tiny link... (If I'm actually able to have an account for open-source projects, that wasn't clear at all from the landing page, it looks like signing up is only if I want to pay for a private team account.)

- Add a link to your homepage on your blog. (The old classic.)

- Don't make your min-width so wide. I mean I'm a dev with a huge monitor and still I had to open up my window to not feel claustrophobic. No page in your app needs to require that much space. Cutting off source at ~80 characters is perfectly fine. (Actually, lots of your internal pages could benefit from having less space instead.)

- Make your climate badge look nicer. Travis's badges are disgusting, so no need to copy them exactly ;) (Retina would be nice!)

- If the "view on github" button is important (I think it is) then make it look important. I had no idea what it did until clicked it because the icon doesn't communicate much. (Plus that "g" is from their old wordmark.)

- The search by class name, badge and tweet button are all different sizes so they feel very awkward next to each other.

- The site is really slow. It takes ~5 seconds to navigate from the feed page to an individual file by pressing the graph. And around 1 second to "view more" on the snippets of code. Generally this just makes me frustrated and less happy to use the product. (The importance of this is often underrated, I know because our own dashboard has this exact problem.)

- Come up with a layout that doesn't need to have the repo name overflow with ellipsis. That's pretty much one of the most important pieces of text on the page, so it's not okay to truncate it.

- Get a yellow with more orange in it for "C". Then it would be possible to still use a white letter. This way your highcharts graphs don't break since the labels are all white there.

- Be more consistent with your color scheme. The greens and yellows on the tour page aren't the same as the in the grading. And they're also different from the colors in the source view. And they're different from the colors in pricing?

- Heyo! Just found the "Solo Plan", op, nope that doesn't solve my problem nevermind.

- There's probably a more understandable way to organize the table of files by the way they are nested in the codebase. you might want a sort of Github file navigator instead. Or at least files that are in the same folder shouldn't be bisected by files that aren't.

- I have no idea what the complexity numbers mean. Or the duplication numbers (is that lines of code duplicated?) Or the churn numbers. Or what "C/M" means. Or the smell numbers. Or why smell is a category, since aren't all of these code smell? Should it be lint instead?

- Having a file navigator would eliminate the need for paging the files. (Really strongly suggest a file navigator because it will feel very nice to browse the same way as on Github. I don't need to see every single file up front. I can just browser through my repo like normal. And then the bad ones are called out on the feed page.

- The refresh button is also confusing, why is the commit shown? (I know why now, but in its current state it's un-obvious, slash ugly.)

- Don't abbreviate "Complexity per Method" to "Complexity / M" just to then have a tooltip on hover that says "Complexity per Method".

- Lines of code count seems broken. Lines of code per method also just shows exactly the same as LOC, which also seems broken. Same with method count. (for https://codeclimate.com/github/segmentio/analytics.js/lib/in...)

- Breakdown over time graph is probably better visualized as a percentage-based stacked area plot.

- Churn vs. quality seems pretty useless to me. Can't think of why that will help.

- GPA is a really bad metric. My co-founder asked (is a low GPA good? because the connection to school GPA isn't clear) Just give me an overall grade like "D" for the repo instead. You can still plot the real number over time but I don't need to know about it.

Hope some of that helps! The product seems very promising. The actual (non-lint) smells it finds are usually pretty good from what I can tell.