While it is a risk, it can be a calculated one. Most household goods require the "platform" of a supermarket or other merchant to actually reach customers. Is this so different? As a consumer, there are lots of benefits to being able to find and discover goods in one place, and as a seller, access to those potential customers can make or break your business, but might not be something you can actually establish effectively on your own without those distribution channels. The same is true of infrastructure - one always has to weigh the risks involved against the costs of trying to do things yourself.
This is certainly true on the low-end, but rarely true on the high-end. Especially when we're talking about kitchen products. The most expensive, sought after fridges, stoves, espresso machines, etc aren't found in retailers.
I was an early Parse engineer (4th engineer to join the company) and now am the SDK engineering lead for Firebase.
The experience of working on Firebase at Google is vastly different from Parse at Facebook, and it shows in Google’s continued commitment to building and expanding Firebase, integrating it with its Cloud Platform products, and otherwise pouring huge amounts of effort into making Firebase great for developers. Open sourcing our SDKs gives us even more ways to engage with the developer community and allows us to be more transparent with the progress we’re making.
This announcement is just a first step down the path toward more transparency with our SDKs, but we hope to foster community and build trust in the tools we’re developing, and welcome your contributions!
That's great! But it does make sense why google and FB would be taking different paths here.
As much as I was disappointed with FB's decision on Parse, I can also understand the reasoning behind it and I actually think it was the right decisions for the company.
In contrast, Google is playing in the cloud service vertical and investing in the future of Firebase is totally aligned with that objective.
Though it does seem kind of odd that facebook isn't playing in that space. I'd be curious to know their reasoning for not launching a competing product there.
Parse is a backend as a service provider -- originally for mobile apps, but eventually for all kinds of applications. You could store data, manage users, target and send push notifications, gather analytics, etc., all without having to build your own backend.
Nice, that sounds useful. I guess it's good that they're releasing some of it as open source then. :)
I've built a couple backend systems for mobile and other, I've used Kafka/zk for messaging primarily.
I'll have to check this out more in depth, thanks :)
That's a very dismissive attitude toward real emotional attachments. The loss of something you've poured your life into can genuinely be traumatic, shocking, and dismaying.
I don't like the notion of applying the "first-world problem" dismissal to things that aren't trivialities. It's one thing to laugh about how you have to get up from the couch to get a remote. It's another thing entirely to talk about major changes to one's career, wiping away years of their work, or the loss of something they care deeply about as a "first-world problem".
Sure, getting acquired might be a "good problem to have", but it doesn't make its toll any less real.
I mean nothing ... violent or otherwise unpleasant by this, but it's really important to learn to let go. You pushed the rock up the hill for a while and now maybe it's somebody else's turn.
IMO, it's important to retain the capacity for grace in these things. Not least for your own sake, much less you're career.
I would read the parts of Shelby Foote's "Civil War" surrounding Lee's surrender at Appomattox Courthouse. It helped. Whatever else may be said of Lee, he was a master of grace under pressure.
Fair enough. There are real and powerful emotions at play.
But it's a bit of a stretch to suggest an employee at a company founded 5 years ago has "poured their life into."
Personally, I'll reserve evocative language of loss for things beyond a strategic shift at the office - but I shouldn't judge others who view things differently.
Consider, briefly, that the relevant question is what it meant to the OP, and clearly for her it had that impact. Having been through many of the same experiences (I, too, was an early Parse engineer, though I left about a year after the acquisition), I can tell you those feelings are real, and that it's definitely possible to form that kind of attachment to your work in well under 5 years.
There's definitely a benefit to developers. Hoomi provides an alternative to social login as well as an easy way to get single sign-on across their suites of applications. Furthermore, developers can adopt Hoomi rather than adding their own email/password-based login mechanism and avoid having to build screens for login, signup, email/phone verification, password reset, account management, etc. Essentially, developers can treat Hoomi as their login-as-a-service provider.
>> Hoomi provides an alternative to social login as well as an easy way to get single sign-on across their suites of applications
How does "an alternative to social login" itself benefit developers? Every other benefit you've listed out is already being provided by social login providers.
Users are reluctant to use social login given the context of social login being sharing. This sharing sometimes results in accidental sharing or over sharing with the application and its users or "friends" on the providers social network.
I'm not trying to be rude, but you're conflating developers with end-users, and didn't really answer my question.
I'm curious how developers specifically benefit from integrating with Hoomi, over other social identity providers.
Developers want to convert as many users as possible into their apps. Social login turns off individuals that care about their privacy. Developers that adopt Hoomi don't have to implement an alternative to social login.
You're exactly right. We don't require email addresses or phone numbers to be requested from users by apps. Those are just ways to get and verify a Hoomi account. Once a user authorizes an app, the app only gets a stable, unique identifier (unrelated to the email address or phone number on the account).
We will eventually have some premium services that developers can get access to that will help them engage with their users or administer their services.
As for "Anonymous" login, that's Facebook's term for the service they promised (and we don't use it in our own description of the product for exactly the reasons you mentioned). We act as brokers between apps and users for their data, which includes an identifier that can be used for login. When an app chooses not to ask for personal data, we let the user know that we won't be sharing any of their information with the application.
OP here. Excited to start showing this stuff to the world. We think identity and login are really broken today, especially on devices that are becoming smarter (mobile, TV, etc.), and we are hoping to provide a solution that lets you take an identity with you wherever you want/need it.
Since we're not a social network, we can avoid a lot of the risk and confusion about how to use the product without accidentally sharing too much information, and really focus on building a first-class identity product.
We're happy to answer questions if you have them. There's more to come, soon!
So, the biggest draw of the social-network-based logins (as well as their biggest flaw) was that you probably already had an account. With Hoomi, what's the advantage of using your Hoomi account rather than just giving an email address?
Also, how does this compare (in both features and privacy) to Persona?
Hoomi sits somewhere between email/password login and social login. Users still get the benefit of Single Sign-on (that grows as more developers adopt), but don't have to have (or tie their account to) a social profile. You're also welcome to use your phone number to create a Hoomi account.
As far as Persona goes, one of the major differences is the primacy of mobile as a medium for login. And while Persona focuses on using email addresses as identifiers, we go one step further than that, isolating users/apps into their own ID spaces that aren't tied to any particular existing identifier. As a result, a user can change their email address with us without disrupting their service or updating their applications (https://developer.mozilla.org/en-US/Persona/The_implementor_...), and users don't have to divulge this information if it's not necessary, as with apps that just use login for personalization.
We're rapidly building and adding features to Hoomi, and you can expect to see the benefits to users and develoeprs grow as we flesh out users' ability to create profiles for themselves that they can give their apps access to.
Unlike Persona, Hoomi will be able to know which application the user logs into, and for how long, correct? From what I've seen so far, it seems like the user and/or the application will have to make requests to Hoomi's servers.
Does this mean that Hoomi will become essentially a single point of failure: if Hoomi's servers get compromised, the malicious agent will be able to collect the user's identities and activities? Especially if a lot of apps implement Hoomi, then it may even be possible for the malicious agent to profile the user's entire digital life by tracking them everywhere.
This is what Persona aimed to prevent: it delegates the responsibility of identifying users to a third party and multiple such third parties can exists. Also, as far as I remember from when I used it, it also is designed to ensure that the authenticator have no knowledge of what the user is up to.
We're encouraging developers to use this alongside social login (or as a replacement for building their own email/password-based login). Developers can avoid having to build and design large amounts of UX around login, registration, email/phone verification, password resets, etc. by adopting Hoomi, while still giving their users an alternative to social login.
We plan to add a number of compelling features for both users and developers. These will increase the value of a Hoomi account as well as the benefit of adding Hoomi login to your applications.
