Other auth providers for sure. We'll be adding shortly.
Using an alternate auth provider won't even prevent you from scanning non-public GitHub code. There's a GitHub OAuth App just for auth (which is what you're seeing here), and a separate GitHub App that you need to install either way to give Detail access to the right repos. We can swap out the former for Google/Okta/pw if you want to avoid this warning. GitHub Apps (the half that manages repo access) have a much finer grained permissions model.
We've run it on a few firmware repos and gotten good results. A lot of firmware code tends to have really poor type-safety which means lots of low-hanging bugs.
We should be able to handle cross-compilation. Want to try it? Ping me in any direct channel ([email protected] / @danlovesproofs) and we can keep an eye on your repo.
Github only for now. Out of curiosity, is yours on gitlab? Something else?
We should be able to find something interesting in most codebases, as long as there's some plausible way to build and test the code and the codebase is big enough. (Below ~250 files the results get iffy.) We've just tested it a lot more thoroughly on app backends, because that's what we know best.
On a personal level I can absolutely empathize, but respectfully, I don't see why that should be the state's concern. The goal of IP law should be to promote the creation of good art, not to make sure artists' wishes are respected.
So, for example, theft should be illegal, because a world of unrestricted IP theft might be one in which we would get a lot less art. But allowing Tolkien to block adaptations of his bestseller 14 years after publication was probably not good for art.
Do bad adaptations prevent good adaptations? Lynch's Dune flopped but Villeneuve had a $165m budget.
We can't know the contrapositive but I don't see why giving the author a veto makes good outcomes more likely, especially decades after a book is published.
To be clear we're talking about the state of the world around two years ago. I'm not a bottleneck for this anymore. :)
Also, this is a bit of an uncharitable read. The calculus at the time wasn't about trust per se, and more about the fact that the relationship between quality of blog content and the content's reach is nonlinear. That means it's worth taking the time to get it right, even if the people best suited to make that happen aren't super available, because the difference between getting on the front page of HN vs not is multiple orders of magnitude. (But I think we get the best of both worlds now.)
> what are your thoughts on having dedicated content writers - like technical writers or developer advocates - working on/owning the blog, vs "all engineers are explicitly encouraged to blog"?
I like this, and I think a good developer relations person who is prolific, sufficiently technical, and can get the tone right can be very valuable for building up a company's visibility. It's a good way to take 80% of the work of writing a post off the relevant engineer's plate and also produce great posts, because the person writing them is a professional writer.
We're small enough right now that we can do well enough with some ad hoc stuff, e.g. periodic slack posts to shake the tree. But this is something we discuss every now and then and the timing will be right at some point, as we scale.
It's easier to justify the cost of a full-time employee if your buyers are also primarily engineers. For someone like Stripe or Twilio, an active eng blog doubles as marketing.