Interviewers: Scott Swigart and Sean Campbell

Interviewee: Joseph Smarr

In this interview we talk with Joseph Smarr, CTO of Plaxo. In specific, we talk about:

• Plaxo’s foundations before the social web

• The value of rich user profiles

• Grassroots development and ownership of personal data

• Sharing personal data as a prerequisite for interoperability

• Navigating irregularly structured data as a coherent whole

• Managing authorized access to personal data across websites

• Relative timelines of media buzz and industry adoption

• Efficiencies from standards as a streamlining force in business development

• The corporate opportunity for social media and its impediments

Sean Campbell: Can you start us out with a little bit about your background and your role at Plaxo?

Joseph Smarr: Sure. I’m the CTO of Plaxo. I was the first employee, so I’ve been there all the way back to early 2002. Plaxo has always been about trying to help you stay in touch with the people that you know and care about in a world that is increasingly fragmented because we’re all using different communication tools and everyone’s moving and getting new jobs and new cell phones and Skype and Facebook and Twitter and everything else.

The services don’t talk to one another, so as you get new jobs and meet new people, you tend to lose touch with people as the information tends to get stale. And that was particularly true back in 2002 before there was really any social networking. Your Outlook address book would just get stale.

Now there are all these online social tools for staying in touch, which help in some ways, because for example, maybe people are keeping their information up to date on Facebook. Still, there is a huge fragmentation because of all the different places that people are connecting and sharing information.

Plaxo tries to sit in the middle of all that and help users make sense of it all. Today, the centerpiece is Plaxo Pulse, which was really the first web-wide, news-stream-style aggregator that pulls together not only the contact info for the people you care about but also what they’re sharing across various social websites.

For us, interoperable systems based on open standards have always been a crucial part of our strategy and our environment, because that’s what enables us to help users connect up all the different tools they use.

A lot of the ethos that has gone into helping promote these open standards has borrowed from the way that open source itself has been developed and how the community works.

Sean: What are some of the particular things that you feel have borrowed the most from open source as it relates to running and implementing Plaxo services?

Joseph: With the explosion of social activity on the web, all of these different websites have realized that it is important to know something about individual users. They no longer think it’s acceptable just to let them have an anonymous account; they need to have a richer profile of them, including who they know, who their friends or connections are, what they’re sharing, and what they’re doing. These are all very important building blocks, and every website has found different ways to address them.

Today, it is still the norm that every website makes you sign up for an account, verify your email address, upload a profile photo, connect to a bunch of friends, and so forth.

That fragmentation itself is very reminiscent of the motivations that led open to source software trying to do away with the need for everyone to do the same work over and over again. This situation is more complex though, because instead of just needing code that you can reuse, you actually need reusable user data.

It is quite common to access user address books stored in Gmail or somewhere similar, rather than trying to get users to type in the details for their 100 closest friends from scratch.

But in the absence of good standards, there was really no way to do it other than to take the user’s Gmail user name and password, log in on their behalf, and scrape out all the data. Of course, that approach has a lot of problems, and not only from a security and privacy perspective. Technically speaking, it’s a very kludgey solution that tends to break a lot and to have performance problems, but that’s what all these sites were doing because there was no better alternative.

Issues like that gave rise to a lot of grass roots open standards to make that sort of data portability work well, including OpenID and OAuth, Portable Contacts, OpenSocial, and so on. They came from that realization that your users want to be able to move their data around between different websites and connect up different tools that they use.

There also need to be common patterns to do that, in a way that doesn’t require a lot of pair-wise business development deals and custom integrations. Portable Contacts is a standard for accessing your contact info, so any site that supports that or consumes that can inter-operate with any other site.

Sean: I see that the notion of collective benefit from each others’ work has something in common with open source. How does that extend beyond simple interoperability?

Joseph: The reason that all of this feels so much like open source is that, just like in open source, there’s an itch to scratch and there are people motivated to help make it work. There are people out in the grass roots saying, “Gee, I don’t want to have to build all that stuff every time.”

There were also people inside big companies that had a lot of data who said, “I don’t like the way things are happening right now. I don’t like the fact that everybody has to scrape my users, and I don’t like the fact that they’re exposing themselves. I get that users are going to want to be able to share their information, but what’s the right way to do it?”

That led to a coming together of a community of people who were passionate about improving things in this area, and they started working on specs in a very ad hoc, grass roots, bottom up way. Even though that effort is very standards-driven, it’s also in tremendous contrast to how standards bodies traditionally work, which are very big, top down, bureaucratic entities that involve paid employees at big companies who spend three years with a charter and all that kind of stuff.

What we’re describing here is completely different from how these specs have been built. It’s been much more in the style of open source. A bunch of people came together, coordinating through mailing lists and repositories and so forth, and iterating until something is good enough that it really starts to make a difference. That’s the story that we’ve been living with the last several years.

Sean: How do you strike a balance between investing a lot of money and time and skill in building a service and getting it out there, versus the expectation that a lot of that will simply be given away?

Joseph: First of all, all of that data is, for the most part, the users’, and not the company’s. If I rated a bunch of movies on Netflix, those are my ratings. Netflix has facilitated that, but it’s sort of weird to say that company should be able to hold that data hostage. It’s as if you couldn’t export your Microsoft Word document into some other format.

People don’t like being locked into one particular technology, because they’ve invested a lot of their own time and effort to create this content. There’s an aspect of this argument that involves sticking up for the customer, but more importantly, great companies don’t build their business purely on data lock-in. That’s a very thin form of real customer retention.

The even bigger point is that it’s not a zero-sum game. It’s very early in the trajectory of the social web, and there are many more sites that are going to need more social stuff. There are a lot of people who really aren’t on the social web and so some worry that if people can get their data out, it will be so they can abandon one site for another.

That’s not what we see in practice. What we see is people want to use lots of different sites. Twitter doesn’t really compete with LinkedIn, and LinkedIn doesn’t really compete with Flickr. They’re all doing quite interesting and complementary things.

They each have their own tone and features, and they’re all suffering from this fragmentation, since they become more useful when more people start using them.

But not everyone is everywhere and they never will be, so the more the users can help connect up the different sites they use and help pull together the people they know and the data that’s being shared, the richer an experience you actually get on all the sites.

That’s why so many sites have started being smart about realizing that they actually have more to gain from being more open. Not only because it’s more user friendly and more empowering, but because they really can get a network effect of growing the pie and having everybody benefit.

You certainly see that in Facebook. A few years ago, a lot of people really criticized them as being one of the most tightly walled gardens. Now if you look at their whole strategy, it’s all about finding ways to take that data all across the web, and they are increasingly using open standards to do it.

Scott Swigart: I do agree that Twitter doesn’t compete with Facebook, which doesn’t compete with LinkedIn, which doesn’t compete with Flickr. At the same time, though, that creates fairly fragmented individuals across the social networking space, and I think this is where you guys come in, to make it easier, for example, to keep up on what my friends are doing without having to monitor all those sites individually.

Talk a little bit about the aggregation of social networking, as well as how Plaxo is doing it versus other approaches that people are taking.

Joseph: If you buy my premise that the whole web is going social and that all of these websites are going to start producing interesting social activity, then you’re right. It’s completely daunting to think that I would have to go to a hundred different sites every day to see what’s new, and that’s where this idea of an aggregator comes in–that I can have the one page that tells me what people are doing across the web.

There’s a nice kind of virtual cycle of being able to find websites and start interacting with them, and then have that shared back out to your friends and know that they’re actually going to reach a wider audience.

If I make a restaurant review on Yelp, then by default, only people on Yelp will see it, whereas if I can share it out in Plaxo, or Facebook, or what have you, then it’s going to reach a much larger audience. That’s good for everybody.

Plaxo pioneered this; before, it was really structured individual websites. It was natural for us, because our whole background had been in sharing out contacts in Outlook, or Mac, or Thunderbird, or Google, or wherever they are, so when people started taking up blogs and Flickr and so on, we started including that as well.

Scott: How do you see the evolution of that sharing having proceeded up to this point?

Joseph: One thing that has distinguished Plaxo is that our user base tends to be adults with busy lives that don’t necessarily want their professional and personal lives mashed together. Because of that, from the beginning we said when you connect with people on Plaxo, you can choose to connect with them separately as family, or friend, or business. You can make custom groups as well, but most people stick to those three.

You can share different things with those different subsets of people. That lets you keep the professional site professional and the personal stuff personal, but you can do it all within one interface. So I don’t feel any discomfort, when my family is sharing family photos or if I’m sharing, personal details, because it’s not out with the entire world.

And that really hasn’t been possible until recently, because if you think about it those early social websites, like Flickr, Digg, and Delicious, they didn’t really have a good ecosystem of identity, privacy, and authorization and so forth. In order to make that sharing work, determining for instance whether you are really the Scott that I meant to share with was a very hard problem to answer.

Basically, the only thing you could do was to make everything public, and as long as you’re comfortable sharing things publicly, then you don’t have to worry about exactly who’s getting your information.

But of course, the flip side is that there’s a lot of stuff that people really don’t want to share publicly. In fact, I would argue that public sharing really is the tip of the iceberg. If you think about the comments you would make in public versus what you how you would talk to your close family and friends, the public discourse is a very small subset.

I think Plaxo is one of the places that have created spaces where people can have more private and more nuanced conversations. That goes for the content and comments as well as the individual context. For example, a very common behavior is that someone will share, say, a public YouTube video into a private Plaxo space and they can have their own discussion about the video.

That conversation doesn’t get swamped by the 13,000 comments by teenagers saying “that was cool!” It also is a completely different space, where people have a different set of expectations about what they can say and who’s going to see it. So I think that really enriches the whole ecosystem.

When we started doing this aggregator in the summer of 2007, there were people who said, “Oh my God, this is the ultimate Silicon Valley geek extravaganza. It’s not just enough to have all these websites; I actually have another site that aggregates them all together. What’s next?” And yet, now it’s become incredibly mainstream not only in part of larger social networks like Facebook, but also Yahoo’s open strategy is all about the standard update stream across different platforms.

Windows Live has a whole activity stream, and even iGoogle now has an update stream. It’s become almost an essential piece of infrastructure across all of these mainstream sites and portals.

Still, the standards haven’t yet kept up with it, so you still have to go and tell each one of these websites all the other sites that you use. It’s very hard to keep track of and type in all your user names, so that’s another area where there is still a lot of fragmentation and a lot of opportunity to make things more seamless and user friendly.

Scott: Well that was my next question which was what kind of hell is it to have to go out and integrate with every single one of these social networking sites that has different APIs, different ways of connecting, pulling data in, and pushing data out?

Joseph: It certainly makes you a big fan of open standards. That’s for sure.

[laughter]

Like I said, this is nothing new for us. Outlook, Mac, and Thunderbird are all totally different too. People used to say, “Boy, it seems weird that you’re opting for open standards when it seems like you’ve got such a competitive advantage from having done all the work to do it the hard way.” We say, “Well, we’d really rather not have to do that work if we could avoid it. We think we’re adding a lot of value on top of that, but we’ll do it if we have to.”

I think the good news with social networks is that at least most of them support RSS feeds, for example, so that does a lot for you, even though there’s still a lot of custom work, in terms of exactly how you get the feed, how you render it properly, and all of that.

There have been some efforts to help standardize that, as well. Early on, Brad Fitzpatrick and I worked on a library that has a whole bunch of regular expressions for a bunch of popular websites. Is it a user name, or is it a user id? What’s the URL format of the profile? What’s the URL format of the RSS? Things like that.

So you could at least ask the user for their Twitter user name and then get all the rest of the information for free, and that’s kept up to date, and so forth. Community efforts like that can help a little bit.

We’ve been moving more toward not just public data, which most people are aggregating, but also data that’s not public that you want to share just your family or friends, for example.

That’s where it really becomes important to have standards like OAuth, which is the standard way of letting a user delegate access to you to have some of their private data from another website, but without having to give away their entire password.

For instance, we have OAuth-based feed integration with Netflix for movie ratings, and TripIt for your trip itineraries, and I think a few other sites by now. In both cases, you can just say, “I want to connect my Netflix account to Plaxo.”

We pop up a little window on Netflix, the site where you log in, and say “Do you trust Plaxo to have access to your movie ratings?”

Then you say, “Yes,” and Plaxo gets back a little API token that we can use to call and get your feed of ratings. If you don’t like it later, you can always go revoke it on Netflix’s side, and then we don’t have access anymore. Plaxo never had to take your Netflix password.

So that stuff is quite a bit more complicated, but when there are standards like OAuth, then it really does just work when it’s done properly. As we get more complex integrations like that, it’s where the open standards really do matter.

Scott: Let’s talk about some of those standards, because I didn’t have a clear understanding of what OAuth was. But it sounds to me like Netflix basically segments your data in terms of what you would have access to if you logged in as yourself, versus a subset of that data that’s available to a different application, if it comes in with a token that’s been given out by Netflix.

So Netflix wouldn’t let Plaxo put a bunch of movies in my queue, but it would let me pull in other information about my movie ratings or some things like that.

Joseph: It’s whatever the user authorizes. In fact, OAuth itself punts on the specific scoping of what access is granted where. That’s up to the website. But it’s more a mechanism for saying that I can ask for access to certain information, and then the user can say if that’s OK or not.

That can all be encoded in one of these API tokens. Some sites let you get everything, but it’s still better than giving away a password. Some sites let you say I only want read access to my address book but not write access, or access to my address book but not my calendar, or what have you.

Different sites do it different ways, but OAuth has a standard way of negotiating that dance, and doing all the crypto and everything so that you can get access to somebody else’s data without having to get their full credentials and impersonate them.

Scott: The first place I bumped into OAuth was when I was looking into Google App Engine. Sometimes Google App Engine needs to punch through your firewall and get data from internal systems so that it can be surfaced in the app running on App Engine (and then the website that that ultimately renders as).

Joseph: It’s also about knowing that it’s really your Google App Engine app that’s trying to access your private data. The thing about OAuth is not only that you’re scoping access, but you’re also identifying who’s doing the accessing.

In the case of a Google App Engine app trying to access your private data, you’ve given this Google App Engine app a private secret that it’s using to sign these OAuth requests. Not just anybody could make a request that looks like that, so that gives you some confidence that you really are giving your information away to the right people.

Scott: That makes sense. What are some of the other protocols in addition to OAuth that you think are important or that need to be there?

Joseph: OpenID is a really important one. OpenID is a way of telling a website, “I already have an account on some other website, and, here, I can prove it.” For example, if I want to come into Plaxo and say, “Gee, I already use Gmail. Could I just log in with my Gmail account rather than having to have a separate password for Plaxo?”

Then Google is an OpenID provider, so I can just have a “Log in with Google” button on Plaxo, and without writing any Google-specific code, it goes over to Google and makes me log in. The dance looks a little bit like OAuth to the user. It bounces me over to Google and says, “Hey, is it OK if you log into Plaxo?”

It bounces back to Plaxo, and Google basically sends over a unique identifier. It’s cryptographically signed based on Google so that Plaxo can trust that this really is Google saying that this really is Joseph.

Then basically that’s a persistent identifier. It’s a URL, and in some cases the users may know their URL. MySpace is an OpenID provider, and a user can just type in their MySpace URL and that’s their identifier. In a case like Google, it’s a long, opaque URL the user would never have to type in, but they can just say, “I use Google,” and Google figures it out.

In either case, though, Plaxo has an identifier for that user now, and a way of authenticating them using the remote site. So now we can have accounts that don’t have local credentials but are bound to these external sites, so we don’t have to make users sign up for a new password.

What’s even cooler is that once you’ve got that kind of secure link established, the user can opt to share information across that bridge. We can not only log in with your Google account, but also ask you to share your name, email address, country, postal code, and other basic profile information so we don’t have to show a user one of those sign up forms.

The user’s already filled that information out, and we can just take it from Google.

Even cooler still is the fact that one of those things you can share is an OAuth token. There’s a hybrid OpenID and OAuth, where as part of the log in with Google, you say by the way, could Plaxo also have not only your name and email address, but also an OAuth token that’s good for accessing your Gmail address book, for example.

In one click, the user can sign up, be in the site, see who their friends are on that site, and start interacting with it, with no passwords being exchanged and no complicated multi-step sign-up process to get all the information we need from them.

It’s totally decentralized. Anybody can be an OpenID provider, and anybody can be an OpenID consumer. The thing that’s standard is just that protocol band for knowing which server is telling me who the user is and what’s that URL they use.

The next time that user returns, there’s a way to check whether the person is still logged in, so we don’t have to make you sign back into Plaxo every time. Again, if the user approves it, we can detect that they’re still logged into Gmail, which most Gmail users just leave open all the time.

In this scenario, you don’t have the lost password or sign in again problem as much, which is a really important building block. The idea that you’re going to have a separate password that you can’t remember and separate data on every one of these websites is crazy.

So I think in the not too distant future, it’s going to become increasingly common that most sites will defer to existing identity providers to do all the heavy lifting for them. That’s especially true because those identity providers not only are likely to have more data and have the user more likely to be logged in, but they are also probably going to able to go much greater lengths to keep that information secure and do the authentication properly.

Imagine if everybody who built a house built their own door locks. Wouldn’t that be crazy? But that’s sort of what happens on the web today.

OpenID is a good success story because, again, it started completely bottom up. Brad Fitzpatrick and a few other guys were back at LiveJournal, and they were trying to figure out how to make blog comments from different service providers work. Now you fast forward and Google, Yahoo!, Microsoft, MySpace, and AOL are all OpenID providers. Again, Plaxo was one of the first places to start taking OpenIDs and saying you can log in this way. Now Facebook’s doing it, and FriendFeed’s doing it, and a whole bunch of other sites are doing it as well.

There’s still a lot to be done there, but it’s a great example of using an open source style of iterative development, with rough consensus and running code, and all of that that has gone from something idealistic and geeky, very quickly, to a fairly mainstream deployed technology that I think is going to have a major impact on the industry.

Scott: It seems like the mainstream press’s attention to OpenID has sort of died down, but you’re seeing more and more adoption of it quietly continuing.

Joseph: Right. It’s like SSL, in the sense that most people aren’t thinking about the crypto going on under the hood when they give Amazon their credit card. It was actually quite contentious back in the ’90s when people were trying to figure out what standards to use, who’s going to be in charge, whether it was safe, and so forth. But now we just take for granted that it all works, and it’s all under the hood.

Sean: A couple of OSCONs ago, the OpenID sessions gave the impression that we are seeing the last phases of a technology that’s about to crash into oblivion.

From what you say, maybe what’s really happened is that the hype cycle around it with tech mags, tech journals, people talking about it has slowed, but the actual adoption is increasing, even though the outward discussion about it has slowed to really not much at all.

Joseph: These things ultimately do get deployed on a human-scale timeline. It also takes users a while to adopt an idea like logging into one site with an account they have on another site. What’s interesting, though, is that Facebook Connect, for example, which is this way of taking your Facebook account and logging into other websites, is not OpenID under the hood, but it’s that same user model.

That’s helping teach a lot of users and a lot of websites about the value of starting with an existing account and being able to go use it elsewhere, as well as being able to share your data more effectively.

There are all these things that are helping create a more common experience that people are used to. Twitter’s actually got a variant that uses OAuth as opposed to OpenID, but it provides a similar means to sign in with your Twitter account.

There’s something about this space that we’re in now that is so frothy and fast moving that it’s really hard to know exactly how it’s all going to play out. But there’s clear value if you can do it right. That’s very easy to measure, by the way, because you can just look at your completion and your abandonment rates, and so forth.

I think a lot of the story of OpenID is that the potential has always been there, but the early implementations were pretty unfriendly to users.

Earlier this year, Plaxo and Google did this thing where now if you get invited to join Plaxo at a gmail.com email address, we can tell you’re a Google user, so we send you through an express sign up with your Google account, which uses OpenID, OAuth, and Portable Contacts under the hood.

We got that smooth enough and user friendly enough that it was across the board boosting all of our business metrics. We put out some papers about it that you can see on the web. This type of initiative means that companies aren’t thinking about who owns the users’ data or what protocol to use anymore. This is something that they can implement that makes their business better, and that’s when it becomes a no-brainer.

That’s been our approach of getting past the hype cycle and into the details that you have to handle well to really make this work for mainstream users.

Sean: I want to be sensitive to the time, so are there any closing thoughts from your end?

Joseph: Just to underscore what I was saying before, I think there’s something very important happening right now in the way that businesses are building software and interacting with each other, especially in the consumer Internet space, but also increasingly in the enterprise space. It’s been in many ways influenced by open source.

I think people haven’t really woken up to just how transformational it is. As more businesses are building their own APIs, and as open standards evolve to integrate these APIs, with the engineering cost falling as a result, it has become less of a bottleneck to make these deals. Hooking up Plaxo and Netflix for me was literally an evening project, because there were APIs on both sides, and there was good intent, and there were good standards.

If you think about the traditional way business partnerships happen, they’ve traditionally been run from the biz dev side first, because engineering was such a scarce resource that you had to really be sure there was a strong business case there before you could justify the effort to go do a bunch of work.

What’s happening now is that you no longer have to do so much work on the engineering side. Increasingly, I’m seeing that it’s no longer necessary to put all of this big biz dev burden in front. Instead, engineers and product people within these companies who are passionate about these integrations can just go do them.

To me, that is very reminiscent of the open source model, where there’s no need for a business case, or a justification of resources, or an ROI calculation. If a bunch of people want to build software, and it’s free, and they can just go do it, they just go do it. The proof is in the pudding that if they build something people want, then they’ll use it.

This idea that you don’t have to ask permission means that there are very low barriers to entry. That’s incredibly empowering, in terms of the number of different integrations that can happen and the flowering of this good work that previously people would have enjoyed, but the transactional costs were too high.

Now that they’re low enough, I think you’re going to see this absolute blossoming of interoperability and new kinds of mashup integrations that people haven’t thought of before.

That’s a pretty fundamental shift, and a lot of people who have learned that mentality from the open source world are applying it toward open interoperability and integration between sites. I think that’s a really positive and encouraging trend.

Sean: There’s also more ability to go from having an idea to proving or disproving it really fast. We’ve all met guys who’ve proven long ago that their idea wasn’t a good one, but they continue to try it.

[laughter]

I guess that’s the dark side of it. You can continually try over and over again with slight variations on this model and burn through a lot of cash to prove an idea that won’t work.

Joseph: It’s becoming cheaper to fail, too, and that allows you to be more fearless in what you try. If you think about Darwinian evolution, that’s exactly what you want. You want people to be able to try a ton of stuff, most of which will fail, so that the few constructive things can bubble up.

Scott: It has impact on internal IT departments, too. They can even try stuff, leaving the land of I’s and E’s and entrepreneurial initiatives. Even internal departments can do that stuff a lot more efficiently. It’s an interesting space for sure.

Joseph: The corollary is that sites and companies that don’t open up are going to be at an increasing competitive disadvantage. I think enterprises right now are a great example. For the most part, they’re not getting these benefits, in terms of services like letting users single sign-on to external services with their enterprise accounts. That’s still a huge pain, and it probably involves business contracts and all that.

That Darwinian evolution and quick flowering that happen in the consumer space are largely stopped by the firewall in the enterprise, when of course there’s as much to be gained inside the enterprise, in terms of cooperation, document sharing, wiki use, and everything else.

But they are really leaving themselves out of that upside. I hope and expect that smart companies will, over time, increasingly open up APIs for their enterprise stuff as well, so that they can also participate in this flowering and growth. That will let them allow new ideas to come in and quickly adopt them without big provisioning and purchasing efforts.

Scott: A year ago, at the Gartner conference, they had obviously planned on having a different type of event, but then there was a massive financial meltdown just on the eve of the conference. In the keynote, the guy said, “I’ve thrown out what I planned to talk about. You’re going to have to cut deep and fast. The companies that survive are going to be the ones who get on this quickly.”

They had planned to talk all about social networking. They said not to forget about it, and that for big companies, this is an incredible opportunity. It’s becoming the norm that everybody knows about it in real life and it becomes the expectation.

When a big company hires a recent college grad who’s used to typing in a Google search string and getting answers back is told to go look in 15 different places for a piece of information, the disconnect becomes obvious.

Sean: Especially since some of those 15 places are in file cabinets. [Laughs]

Scott: Companies tend to have archaic systems where the information isn’t shared, so they were really pushing IT leaders to factor social networking into their planning, their internal systems, and their customer facing systems.

Joseph: The reason I like being in the consumer Internet business is that you live or die by whether people actually get value from using your service. That is exactly the right evolutionary fitness function if you want to produce a lot of really good, really user friendly, really valuable software.

On the enterprise side, it’s still not really like that. They’re deploying some enterprise social network, or wiki, or whatever that’s generally a purchase made at a high level, based on a bunch of contracts and whatever else.

Whether or not the individual end users are really getting the maximal value from it, compared to something else, is not what’s being directly captured or correctly selected for. If some better alternative comes along, it’s expensive to swap it out. So it’s no surprise that you have a lower degree of fitness for that kind of software in the enterprise than out of the consumer space.

I think the only way to get around that, which ultimately is what companies need to do if they want to spend less and be more productive, is to remove those barriers toward employees being able to use the tools that actually work for them.

It seems to me like it’s inevitable, although it will take frustratingly long given what we’ve seen. I think there’s a lot of reason to believe that that’s going to ultimately be a really good thing for companies, employees, and software developers alike.

Sean: That seems like a good place to wrap things up. Thank you for talking with us today.

Joseph: Thank you.

Bookmark this: