I hate to have to do this, but given this is a rip-off of a WorkOS product I feel I need to step in here. (I'm the founder of WorkOS.)
Sam and Michael were both brief employees at WorkOS in 2020 where they contributed to our product and were privy to our full codebase, strategy, and roadmap. (We are very transparent internally.)
Both of them were let go from the company. Sam then decided to start working on this open source clone of WorkOS. There are striking similarities in the API structure and architecture of Osso, enough to clearly not be coincidence. Our lawyers sent him a cease and desist but he has persisted working on the project.
This is an unfortunate situation and it’s disappointing to see Sam misrepresent the origins of the Osso project. (He even took WorkOS off his LinkedIn.)
Personally I’m a big fan of open source and open source based business models. (I was responsible for open sourcing Nylas Mail and the underlying Nylas Sync Engine while I was CEO there.) But this form of blatantly ripping someone else’s work and passing it off as your own just isn’t right.
We’re prepared to pursue legal action against Osso if needed, but honestly we’ve just been too focused on growing WorkOS. Today WorkOS is already powering enterprise SSO for a bunch of big companies and also many startups/SMBs and growing quickly. We’re also SOC 2 Type 2 certified and super well funded (unannounced rounds) with a fantastic team.
So I’m posting this mostly to call-out bad behavior and to stand up for our team’s hard work. They deserve it.
And I thought they were improperly profiting off the term 'open source'. But they also are (allegedly) ripping-off another's work? That's not cool at all.
Intentionally shifting the meaning of the term opensource is unacceptable. Open source means surrendering your monopoly over commercial exploitation of your code.
Thanks, we'll review this and other folks' comments and see if we can make a change that works for us and maintains an OSS ethos. This is our first launch FWIW, we're appreciative of the feedback but clearly seemed to have ruffled some feathers
Unpopular opinion: this is the natural consequence of squatting self-descriptive phrases. Open source is self-descriptive.. the source is open. The phrase was hijacked (by the OSI) and is being squatted on by people who want to enforce a very specific meaning of the phrase, even though it is self-descriptive and broad. If there is any ambiguity as to the phrase, it should be added to with modifiers, and not just claimed. For example, what does open refer to in OSS? Lots of different things. Thats why you should specify when addressing your interpretation. OSS should be an umbrella phrase that covers the multitude of interpretations like source available, FOSS, FLOSS, etc.
I've thought about making a nonprofit called the Grape Initiative which would release a definition of "Grape" that only includes purple grapes. If people want to refer to green grapes well then I guess they will just have to say green grapes! When I think about grapes I always think about purple ones, makes sense to me!
>> The phrase was hijacked (by the OSI) and is being squatted on by people who want to enforce a very specific meaning of the phrase, even though it is self-descriptive and broad
I'm not sure that's a very generous interpretation.
In our industry these terms have very specific meanings. Just like other words in Physics, Law, or Medicine have very specific meanings to those in the field, but not to outsiders.
When we say Open Source, we use a two-word description to describe a much broader idea. Likewise when we say Free/Libre Software, we describe software licensed under specific conditions. Its obvious for us in this field why Google Chrome is not Free Software, but not so much for the average person.
>> OSS should be an umbrella phrase that covers the multitude of interpretations like source available, FOSS, FLOSS, etc.
I understand where you're coming from, but unfortunately OSS already has a strict definition. I agree there is a need for a more correct categorization, but it should be strictly and nomenclaturally separate from Open Source, to show that it is a much more restrictive license.
The other industries you mention have gone through similar changes though haven't they? Not long ago, "idiot", "imbecile" and "moron" were all terms with strict definitions in the field of medicine. Languages, terms that are strictly defined, even terms that are particular to a science or industry, evolve over time.
That is absolute nonsense. The people behind OSI worked long and hard to find a term that could be instead instead of Free Software, which they considered to have unfortunate connotations. This is something some disagree with, but that was their cause regardless. Their due diligence of the term took great trouble to make sure it had not any undocumented previous use.
Of course the words had occasionally been used together, but not as a term. That would have undermined their legal strategy altogether. They then failed to secure the trademarks they wanted, but not because the term had any documented previous use.
You may disagree with the outcome, you may disagree with the OSI altogether, but it is wrong to misrepresent history.
> Their due diligence of the term took great trouble to make sure it had not any undocumented previous use.
Doesn't mean an organization should be able to just take a self-descriptive phrase, say purple icicle, and assign a very specific meaning to it. Every self-descriptive phrase has an existing usage. Because one day you'll see an icicle that is purple and say "hey, purple icicle" only to have a horde of people rush and say "thats not a purple icicle!" (literally what happened in this thread).
> They then failed to secure the trademarks they wanted, but not because the term had any documented previous use.
No, of course they didn't have any documented previous use. "Documented previous use" being reserved uses before. You know why? Because it is a self-descriptive phrase that is too broad, ie descriptive mark which aren't granted. They chose a very basic self-descriptive phrase (frequency of previous use doesn't matter) and literally could not get it trademarked because it is self-descriptive and broad, but YET CONTINUED ON even after being swatted down by trademark offices around the world. Absolutely bonkers.
Was the phrase open-source actually used in the generic way you describe within the industry, prior to OSI coming on the scene? Im not sure that it was, but i could be wrong. Regardless, the definition is pretty fixed now.
Nonetheless, you're right, words are hard, and this isn't a new argument about the suitability of the term "open source". RMS makes a similar point about the term in this rather old essay: https://www.gnu.org/philosophy/open-source-misses-the-point....
I've got to agree here. We - as an industry, not a cult of naysayers - need to evolve our views of what is 'in the spirit of open source'. BSL fits that definition from my eyes.
Certainly a fair critique, and one we can admit we saw coming.
We currently use the BSL license, created by MariaDB and used by companies like Sentry. We do think Osso is open source by common understanding and view the BSL as a fair model that places no restrictions on good actors - the license is intended to protect us from copycats profiting off our work, while allowing anyone that needs to integrate SAML into an app they’re building free reign. You’re free to use Osso as a widget, but you can’t use it to start a widget factory.
"Source available" seems like a fair compromise, thanks for the suggestion.
> "We do think Osso is open source by common understanding and view the BSL as a fair model that places no restrictions on good actors - the license is intended to protect us from copycats profiting off our work, while allowing anyone that needs to integrate SAML into an app they’re building free reign."
The common understanding of open source is that source code is available, redistribution free, and derivative works are allowed.
MariaDB specifically states that BSL isn't open source:
> "We have not certified BSL as complying to the Open Source Definition by the Open Source Initiative (OSI). However, all source code is available from the start and most of the OSI criteria are met. As long as the software is used within the usage limitations, it’s free to use at no cost."
As I've mentioned or alluded to in other comments, I think "open source" as you describe it is broken and unsustainable, and we're happy to have a constructive conversation about commercially viable open source. But if we can't agree that the definition of "open source", like any word or phrase, can change over time, then I don't think there's much of a constructive conversation to be had. Would you suggest we remove any mention of "open source" from our documentation etc.?
> I think "open source" as you describe it is broken and unsustainable,
Then dont claim to use an open source license. Its just recently people have felt foss is commercially viable. For most of its history people believed that foss was not commercially viable. That's why it was considered a radical view.
You want to have the cake and eat it too. You're trying to ride the wave of goodwill that open source provides without paying your dues. Yes open source makes it harder to be commercially viable. If it didn't, if it only provided benefits, everything would be open source.
> But if we can't agree that the definition of "open source", like any word or phrase, can change over time
If i sold nut free chocolate bars, and then someone died of alergic reaction, to which i responded by saying, definitions change over time peanuts arent included in nut-free, would you accept that?
Yes, words can in principle change over time - but you can't just change meanings unilateral, especially not as part of a false advertising campaign to mislead users into thinking you are something that you are not.
I don't think I've changed the meaning unilaterally, others here seem to agree that the meaning is evolving.
I can concede that we are guilty of wanting the wave of goodwill, but I have a hard time agreeing that this is a bait and switch. And I certainly hope nobody is going to die because we use "open source" instead of "source available".
The part of this conversation that leaves me wanting is that it all seems so positive rather than normative, and doesn't consider the benefits of choosing this license over a closed source product.
Our goals here are to make SAML SSO more accessible and run a business that helps some good customers use the software we've created. There's a lot of net positives in that IMO, and this whole "but it's not ACTUALLY open source" is a distraction borne of inflexibility and a lack of creativity.
So how do we as an industry move forward in a way that allows individual use of source available software, but prevents companies from unfairly profiting off of that? Is that desirable? What do we call that? Maybe business source, maybe source available is fine. That's a lot more interesting of a conversation to me. If you won't have that conversation until we strike open source from our website I understand.
> There's a lot of net positives in that IMO, and this whole "but it's not ACTUALLY open source" is a distraction borne of inflexibility and a lack of creativity.
Being "flexible" and "creative" with the truth is just a fancy way of saying lying.
Are you seriously arguing the ends justify the means, where the end is some cloud saml business and the means is misrepresenting the licensing terms of your product? That's probably the lowest stakes ends justify the means argument i have ever heard and is pretty rediculous.
At the end of the day, if you can't operate your business ethically and with integrity, then no, its not a net positive. This is true for pretty much any business venture, but its especially true for some random cloud offering competiting in a market with many other competitors doing roughly the same thing. The way you talk about this stuff you would think you were trying to solve world hunger.
> If you won't have that conversation until we strike open source from our website I understand.
Why do you think i'm interested in that conversation at all? I have no stake in your company, i don't care how you structure your IP, if you succeed as a company or if you fail. I do however have a stake in the open source movement and care deeply when parasites try to profit off it without fulfilling their obligations to the movement.
> Certainly a fair critique, and one we can admit we saw coming.
So you intentionally made false statements about your product, which you knew ahead of time were false and if believed might conceivably make people more likely to buy it? That's normally called fraud.
The long winded justification doesn't matter. You're under no moral obligation to make your product open source. You are under a moral (and probably legal but ianal) not to do bait and switches.
I don't think we've intentionally made false statements nor committed any fraud. But we appreciate the feedback, we'll review as a team and see what sort of decision we can make that will maintain source availability without upsetting folks who allow OSI to define "open source". We made some mistakes, we're very early, and we were hoping to have a (constructive) conversation around licensing and sustainable open source.
Right on. This kind of thing keeps happening. Fortunately, HN and other communities have a surprisingly sharp eye for these lies and can generally be relied upon to call them out, but people still try it on.
You are absolutely free to use Osso's source to onboard and authenticate your own customers without paying us! The goal of the license is to prevent someone from creating their own SAAS offering that competes with ours. Using Osso for your own app is within rights granted by the license.
But to your point, we also offer a demo instance that you can use in order to build out your integration, and then when a customer comes along, start paying us and swap out some ENV variables and you're ready to go!
Hey HN! We're Sam, Sam, and Michael, the founders of Osso (https://ossoapp.com/)
Osso is open-source software for integrating SAML SSO with any web application. It provides an Admin UI to onboard your customers, generates custom documentation to configure your app in a customer's Identity Provider (IDP), handles SAML authentication against IDPs and provides your app normalized JSON profiles as part of an OAuth 2.0 code grant authorization flow.
We started working on Osso together as a way to keep in touch and distract ourselves from, well, *gestures broadly at everything*. We chose to work on something that each of us came up against during our careers: supporting SAML SSO. Between the three of us, we've built internal tools where SAML was required by IT and struggled to sell SaaS products that didn't offer SAML SSO to enterprises who required it. We've also been users of various IDPs, limiting us from accessing the apps we wanted at work when they only included SAML SSO on the way-too-expensive Enterprise plan.
Every successful SaaS company builds SAML SSO eventually but it's never a top priority and nobody takes time to really understand it. If your customers want SAML, it's a great problem to have but chances are there are thousands of other things on your list. Most teams end up kicking it down the road, which can lead to lost sales opportunities. Companies end up piecing something together that kind of works but creates technical debt or support burden, or they spend thousands of dollars on Auth0 or AWS Cognito, but still lack customer docs or a streamlined flow for SAML onboarding.
So we're trying to simplify things for SaaS companies to make SAML SSO a more accessible option. We took existing open-source software and added the last 10% to make integrating a scalable, sellable, and serviceable SAML SSO solution as easy as possible. All the code is available on Github for you to run on your own, but we also offer a SaaS solution where we'll manage an Osso instance for you.
Osso:
• Treats SAML like OAuth - connect your app to an Osso instance via OAuth, and Osso will handle the SAML authentication and return normalized JSON profiles
• Enables first class support for Azure Active Directory, Okta, OneLogin, Ping, Google, and Salesforce, yet works with any IDP that supports SAML 2.0
• Features an Admin UI for customer support / success teams to onboard and support customers
• Provides a convenient interface for technical teams to create and roll OAuth clients and their secrets
• Generates custom PDFs for step-by-step onboarding for each of your customers
If you're interested in learning more, start here:
The back end is a few modular Ruby/Rack apps including a GraphQL API and an OAuth 2.0 server, while the front end is a React app written in Typescript. We use a modular and package driven approach, allowing you to customize your Osso instance with theming or middleware, or pick and choose parts of the stack to use, while getting critical updates through our Ruby gems and npm packages. We offer client libraries for Ruby (omniauth-osso) and NodeJS (passport-osso), and are working on React components you can use to interact with your Osso instance, like a login component and a widget to allow your customers to configure SAML themselves.
We really appreciate the HN community and the discussion that takes place here, so we hope you'll provide honest feedback on Osso. What's missing? What should we do differently? Anything you'd take away? We look forward to reading and responding to your comments, but if you want to speak with us directly you can also email us at hello@ossoapp.com.
Looking at your license, it looks like it limits production use to "internal business purposes" and does not allow providing "access to the Licensed Work to a third party." To me that reads that this is not at all usable as open source for a production SaaS app serving external customers, only for internal intranet apps. I don't think it's appropriate to advertise this as "Open-source" with such a restrictive license.
So the intent of the license is to prevent copy-cats from using Osso's source to run a competing business. We certainly intend for you to be able to authenticate external customers in a SAAS app. IANAL but the license text hsa been vetted by an attorney.
Is our intent with the license enough for you to consider it appropriate for us to call this open source?
Absolutely not, contract law cares most about what is written in the actual contract, not what you say you intended by it. There is no way I can risk using this in a commercial SaaS app given the license as written. In comparison, Sentry's BSL license (which you mentioned in another comment) does not have the same flaw. I can use open source Sentry to monitor my commercial SaaS app no problem based on how their license is written.
I didn't mean for you to take my comment as a guarantee, but if you're more than curious I'd have your counsel read the license, as we are under the impression the use you describe is well within the rights granted by the current license. Put another way, do you consider Sentry "open source"?
Armin from Sentry here: obviously biased but the term I like the most to describe BSL as used by Sentry is: eventually Open Source.
The BSL upgrades automatically to Apache 2, so the only thing that it does is establishing a time window where there are some restrictions on the code.
A theoretical version is one where you just only release code with a large delay under the Apache 2 license and keep the rest closed source. That's also still technically open source but I would argue that's not a particular good version.
> How are the contributions managed from community?
Depends. Many places where the community contributes are just flat out open source licenses. For instance all our SDKs or certain backend services like our symbolicator service.
We don't have a lot of contributions going to the BSL licensed content for this to be much of a concern at the moment.
They aren't in our case. Open Source doesn't have to mean community built, and Sentry (the product) is built almost exclusively by our company. Our philosophy is something along the lines of: Pull Requests are nice, but we'd rather you just give us open feedback and support the project in other ways.
We do accept PRs, and do have a large contributor community, but its primarily things like SDKs or documentation. The core product is complex enough that making a significant change - even if its one we agree with - is a hurdle.
I don't want to get into a philosophical debate about what is "open source," but I have no issues with how Sentry advertises and documents their licensing or in how their custom terms are actually written.
Fair enough. I stand by our interpretation of the current license though - the usage you describe is fair use, but let us know if your attorney disagrees as we'd definitely want to fix that.
I think you dont know what the term fair use means.
Commercial use of a copyrighted work in a way that directly competes with the purpose the work is being sold for is almost certainly not fair use. Hell its almost the definition of what something not covered by fair use would be.
> Companies end up piecing something together that kind of works but creates technical debt or support burden, or they spend thousands of dollars on Auth0 or AWS Cognito
I built something out with Cognito for my current team. I don't like it much, but we're definitely not spending thousands of dollars on it. Have you heard horror stories about its pricing?
From the AWS pricing page (https://aws.amazon.com/cognito/pricing/), you get 50 MAUs with SAML free and then it's $0.015 per user. We haven't had any issues with this - yet.
I do think your solution sounds nicer, but I'm really not sure looking at your pricing that it's cheaper.
The pricing here is definitely more applicable to Auth0 :)
But for us, charging per user makes predicting the cost of your SAML provider difficult, and everyone seems to do this. We charge per customer account instead - if one of your customers has 50 MAUs it wont cost you more than a customer that has 10. And you won't need to pay us more is your software is a daily driver vs. something thats used lee frequently.
Ah great point, I wasn't thinking about how many users a single customer could potentially have. I'll definitely bring this up if we do end up onboarding more customers using SAML, Cognito is definitely not ideal for admins/documentation.
Congrats on the launch folks! Would you mind outlining why SAML specifically is hairy? How is it different from OAuth (for people who aren't doing a bunch of auth work on a daily basis, or haven't reached a scale where SAML is an issue yet)?
A useful framework for thinking about SAML vs OAuth from an engineer's perspective is to think of OAuth as class based, while SAML is instance based.
When you set up a new OAuth provider such as Github you typically grab a Client ID and Secret, specify your redirect URIs, and once your integration is complete any Github user can sign in with a Sign in with Github button.
But with SAML, you need to perform configuration with each customer's Identity Provider instance. As you pull on this thread you start to see where the challenge with SAML lies. SAML as a protocol isn't super complicated, and tons of OSS already exists to perform authentication. But you need to create and persist configuration data for each of your customers, which suggests needing a UI to perform this onboarding. You need to help your customer configure your app in their IDP, so you'll want to create documentation. And you need to adjust your sign in flow - you can't just stick a Sign in With Okta button, you need to ascertain from the user which IDP they use for authentication.
Osso though handles all of the "instance based" challenges, and allows your app to use OAuth to communicate with your Osso instance.
Congrats on the launch! I work at Oso [1], also an NYC-based security startup but with half as many consonants and co-founding Sams. cue spiderman meme
Wow, this is amazing at first glance. Will definitely have to dive into to see that it hits all the requirements. But as someone who trodded down this rathole when a client asked if we supported SSO, it would be an amazing utility to have around.
How battle tested is this with real companies and different IDPs?
In any case, congrats on the launch and will definitely be taking a closer look.
Thanks so much! We're super confident in the 6 IDPs we've built first class support for. But we also know that there are sure to be edge cases we haven't totally caught, we're still a bit early. But at least we can catch those across our customer base, as opposed to you finding them ll in your one-off SAML integration.
We have to really manually test real IDPs, and we do whenever we release new software, but we also run e2e cypress tests against a Mock IDP we built, so SP -> Osso -> Mock IDP -> Osso -> SP, you can see these in our Buildkite CI - https://buildkite.com/enterpriseoss/osso
We don't have definite plans to build a full-featured IDP, but we did build a Mock IDP we use in CI, QA and demos that could possibly be a starting point for your purposes? Other OSS IDPs include Keycloak and Gluu Server if you wanted to check those out!
Frankly we're using existing open source to handle this - we use ruby-saml which is maintained by OneLogin for the SAML parsing, but we also wrote a little ts parser for federated metadata files - https://github.com/enterprise-oss/osso-react/blob/main/src/u...
Sam and Michael were both brief employees at WorkOS in 2020 where they contributed to our product and were privy to our full codebase, strategy, and roadmap. (We are very transparent internally.)
Both of them were let go from the company. Sam then decided to start working on this open source clone of WorkOS. There are striking similarities in the API structure and architecture of Osso, enough to clearly not be coincidence. Our lawyers sent him a cease and desist but he has persisted working on the project.
This is an unfortunate situation and it’s disappointing to see Sam misrepresent the origins of the Osso project. (He even took WorkOS off his LinkedIn.)
Personally I’m a big fan of open source and open source based business models. (I was responsible for open sourcing Nylas Mail and the underlying Nylas Sync Engine while I was CEO there.) But this form of blatantly ripping someone else’s work and passing it off as your own just isn’t right.
We’re prepared to pursue legal action against Osso if needed, but honestly we’ve just been too focused on growing WorkOS. Today WorkOS is already powering enterprise SSO for a bunch of big companies and also many startups/SMBs and growing quickly. We’re also SOC 2 Type 2 certified and super well funded (unannounced rounds) with a fantastic team.
So I’m posting this mostly to call-out bad behavior and to stand up for our team’s hard work. They deserve it.
More background on WorkOS for those curious:
- WorkOS “Show HN” launch (March 2020): https://news.ycombinator.com/item?id=22607402
- Our recent Fall Release (Nov 2020): https://youtu.be/JP-9wVoqy4A
- “Crossing the Enterprise Chasm” (August 2019): https://youtu.be/IR2QZQrzoiA
- WorkOS API Docs: https://workos.com/docs