i can't count the number of products i've worked on or adjacent to that have gained some traction, started to scale... and hit a brick wall when wanting to access the enterprise market. far too often, these projects end up stopping most core feature work to add hacky versions of whatever's required to close that enterprise sales gap. they slow velocity while incurring tech debt.
a SaaS product that offers some developer-friendly ways to drop these capabilities into your system could be a huge win for companies at that inflection point.
While I agree, an SSO login wall is really the most trivial of these enterprise features to implement. Even the most basic SaaS app out there supports it already, and there are enough libraries in every language you can use. So while WorkOS might make things easier in that area, it won't be a game changer, at least not with its current feature set.
Start talking about compliance with a hundred different standards (ISO/IEC, SOC, CSA, GDPR, APEC, HIPAA, FINRA, FedRAMP), data residency, eDiscovery, audit logging, RBAC, invoicing, uptime SLAs, analytics, MDM, disabling features and your customers will be a LOT more interested.
I've seen a SaaS app team who couldn't implement OIDC because their login screen is actually some kind of maven plugin (so they don't control it). They can't move to the latest version of that plugin that does supports OIDC, because that needs the latest Maven version. They're using a BPE (process engine), though, that is end-of-life and won't work with the latest Maven.
They're in dependency hell. So we put their whole app behind a proxy that does our SSO.
Vercel helps make the web. Faster. You might know us as a front-end centric platform, but that's all enabled by a lot of fascinating infrastructure. We're hiring multiple product management roles within Infrastructure, and have a lot of challenging problems to solve around our network/edge systems, our core and build systems, and our data transit and delivery systems.
FWIW, I would LOVE to see openCypher supported on dgraph! I find it far more expressive and easier to work with for many types of traversals and logical operations.
the combination of the Import and Call Graphs (https://github.com/github/semantic#language-support) should allow for the construction of a view of what symbols are imported, and where in a given project they are called. resolving those edges across repos is also possible, in many cases.
very doable, at least for certain types of clones, and a topic of active research.
while leveraging the ASTs and scope graphs produced by semantic can allow you to attack the more complicated clone types (eg, code that has nearly the same meaning, with significantly different implementation), various parsing + hashing methods have proven useful for the more simple cases.
useful for far more than detecting plagiarism, too. it can boost signal for search, allow for more nuanced semantic navigation, assist in refactoring, and help understand the propagation/provenance of code (which can be important for understanding licenses, etc).
