“only $10 so I call 1st world problem.”
— @ignatiusmusic (giving some needed perspective)
There’s been a lot of traffic on Twitter about Sparrow over the last 24 hours. Sparrow is a $10 email client App for Mac OS X and iOS. The Sparrow company has been acquired by Google. As far as I can tell there will be few or no further Sparrow updates. Some Sparrow users are not happy.
I never used the App. I have no relationship with Sparrow. I’ve been watching the mobile App market with interest for a while. I look at the case of Sparrow and see some interesting things. I see muddled user expectations and confusion about user-developer relationships. Confusion that perhaps arises out of the nature of the “App” product model.
Matt Gemmell has posted a provocative rebutting of unhappy user’s tweets about the Sparrow acquisition, you should check it out. Matt’s post and the conversation that followed inspired me to write this. Much of this is a commentary on Matt’s post. Hopefully I’m adding something to the conversation.
I’ll get back to Matt’s post in a moment. But first let’s look at the announcement from sparrowmailapp.com:
We’re excited to announce that Sparrow has been acquired by Google!
We care a lot about how people communicate, and we did our best to provide you with the most intuitive and pleasurable mailing experience.
Now we’re joining the Gmail team to accomplish a bigger vision — one that we think we can better achieve with Google.
We’d like to extend a special thanks to all of our users who have supported us, advised us, given us priceless feedback and allowed us to build a better mail application. While we’ll be working on new things at Google, we will continue to make Sparrow available and provide support for our users.
We had an amazing ride and can’t thank you enough.
Full speed ahead!
Dom Leca
CEO
Sparrow
For me, the announcement reads as focused on the Sparrow team and their achievements. They’re passionate about creating an “intuitive and pleasurable mailing experience.” They have a bigger vision and they’re excited to have the opportunity to reach for it with the help of Google. As some have suggested, we should be happy for the Sparrow founders at this exciting point in their careers. Indeed from a business standpoint it is a great outcome. The flip-side is that there are now a bunch of Sparrow users with an App at the end of it’s life.
The announcement appears on the front page of the Sparrow website. I’m really not sure who the announcement is addressed to. A natural assumption is that it is addressed to Sparrow users. However, it is not until the fourth paragraph that users are mentioned. Users are thanked for their part in the process, and in the fifth paragraph, thanked for giving the founders “an amazing ride.”
I can understand the founder’s excitement. But is this really what the users need to hear? For users, product EOL is an unhappy day. Developers should be mindful of that.
The response has been predictable. Sparrow users are not happy. As I mentioned above, Matt Gemmell has rounded up a bunch of user responses.
Matt describes a mismatch of expectations between users and developers. He uses the word “entitlement” as if user’s responses are out of line. Perhaps they are. Clearly there is a disconnect between Sparrow and user’s expectations. Are the users at fault for having these expectations? I’m not sure. Where did these expectations come from? Are they well founded? I don’t know for sure. What is clear is that users are not getting what they expected. I don’t think this can be explained by writing them all off as a bunch of self-entitled prats.
Matt appears to take the view that the unhappy users were ill-informed and that they need to wake up, adjust their expectations, and accept the reality of the situation. Well, maybe. We all have expectations about relationships, business or otherwise. Sparrow is appliance-like technology used day-in-day-out. Perhaps the expectation of product continuity is reasonable.
Matt writes:
If you’re a developer, then you really need to get your head straight. You’re probably being a hypocrite. This is you:
1. YESTERDAY! “I hate how people feel entitled to future versions of my app after paying $10.”
2. TODAY! “I feel betrayed that Sparrow won’t be updated anymore after I paid $10.”
Pick one.
True. If a developer is thinking like this they are a hypocrite. Maybe some developers do have the attitude (1). I haven’t met anyone with this attitude. It if it’s true, that’s unfortunate, because guess what? delivering software is about relationships and service. Whether or not your business has “SaaS” as a business model, software is a service. People reasonably expect support, bug fixes, updates. Maybe it doesn’t come for free, perhaps users are not prepared to pay what it costs, none the less these things are all a part of how software works today. In this context, are expectations really misplaced entitlement?
Maybe I’m missing the point. Perhaps the mobile App world is different. Software-as-a-disposable-consumable, with only the big companies willing and able to deliver service, support, updates and product continuity. What do you think?
On to some of Matt’s other points:
You don’t get much for $10
For $10 you might get a great App, but you’re not buying service, or support, a relationship, or product continuity. You’re buying a one-time hit. The App-store model is based on selling a steady stream of low-priced licences. It’s a high-volume low-margin business.
If you start from this point, all of Matt’s rebuttals are hard to argue with. It’s true. You don’t get much for $10. Is this really the culture of commercial software supply and development that users want?
Wait, there is ambiguity here. Apps auto-update. The App store can withdraw the App. There is an ongoing relationship. It’s kind of like a disposable-consumable with a built-in auto-update service that can be obliterated at any time.
Don’t buy promises about the future
The Sparrow team promised certain features. Users claimed to buy the product on the expectation that they would be delivered. Matt criticises Sparrow for making promises and the users for making purchasing decisions based on them. Here’s what my AudioMulch What’s Coming page says:
About the Future
This page used to be called “roadmap”. Roadmaps can have many purposes: to create a guiding vision for future development, to give a vague impression of what we think might happen, to try to get you to buy something that doesn’t exist yet. We don’t want to publish those kind of roadmaps. We have tried not to include things here that might happen, even if we think they’re important or could be useful.
In disclosing future plans there is a line to be navigated between being open with users and over promising. Users who have invested their time and attention in a product (and it is this investment, more than the money that is important) deserve openness. On they other hand, they need to understand that conditions change. “All specifications are subject to change without notice.”
Honour and betrayal
Cole Peters suggested that it’s a matter of honour to ensure product continuity: developers should decline an acquisition if product continuity can’t be ensured. Other users feel betrayed. Matt is pretty uncompassionate saying, “You weren’t betrayed, though, so why should anyone care?” Maybe there is no contractual condition, but clearly there was an expectation of relationship and honour here, at least from one side. How did that happen? Is it unreasonable? Why? Do developers know they are “leading users on”?
Modern app development is often a collaboration between developer and user. Users put a lot of effort into the collaboration. Value does flow from user to product. Is thanks for “an amazing ride” really the way to end the relationship? If I were a customer I’d be confused.
There is honour in every customer relationship, and there is honour in serving customers and delivering product continuity. How far the honour stretches depends on many things. It’s not black and white. There are reasonable and unreasonable expectations to be sure. What are reasonable product continuity expectations for Sparrow? for any $10 App? for any email client App? What if it were a GUI framework, or a whole operating system? Does anyone really know? Seems like there are a lot of differing opinions out there.
Reading Sparrow’s announcement it’s pretty clear that the Sparrow founders are “Full speed ahead!” with the Google acquisition and are acting in their own best interests. The user’s best interests don’t seem to come in to it. In the end maybe their user’s best interests will be served. Maybe in a year’s time every Google user will have something better than Sparrow available to everyone for free. There’s always a bigger picture.
Open Source
“When software you use and rely on suddenly becomes discontinued,
you begin to understand what all those GPL guys are really talking about” — @tolmasky
It’s hard to know exactly what “GPL guys are really talking about” but perhaps @tolmasky means product availability, maintainability, and continuity. Releasing the source is one way to deliver some form of continuity after acquisition. However it takes more than source code to deliver an App. Would an indie FOSS project give Sparrow users what they expect? Matt doesn’t think so. I’m not sure either.
The kind of app that’s developed under a commercial start-up model is often quite different from what is produced in the Open Source world. So are the users. The key ingredients to many commercial Apps is not source code, it’s everything else: user experience design, graphic design, support, quality assurance, project management. There are surely counter examples, but I don’t see many indie open source outfits delivering the same kind of polish as commercial Apps. Guess what? Open Source users don’t care. The Open Source stuff still works. But that doesn’t make it a solution here.
Perhaps people want the combined benefits of commercial Apps and Open Source Apps. If you know how to develop innovative software that delivers all the benefits of both models, in an indie environment that is economically sustainable, I’d love to hear from you. Seriously.
Anger and grief
Matt quotes a bunch of angry comments. Anger is maybe not the best way to deal with losing an App, but it’s an understandable human response. I’m not going to defend the haters, but clearly they expected a different outcome.
Matt makes more good points about indie development and the success of this acquisition for Sparrow’s founders. I’ve said enough. Go check out Matt’s post.
Closing thoughts
For me, the Sparrow acquisition highlights issues that arise in a climate where for many, the holy grail of developing end-user software is not to serve the user, but to sell the company.
Lean development practices encourage delivering a minimum viable product and iterating development in collaboration with users. What is the relationship of user to product in this collaboration? Can users reasonably expect to be considered investors? Maybe not for their $10 App purchase, but perhaps for their participation in the development process. Typically the pay-off is seeing the features they want implemented. What happens when the App is EOLed and they can’t access those features?
Today the relationship between user and developer takes many forms. From free web Apps and services, commercial SaaS, through to shrink wrap desktop applications and bespoke development services, the terms of each relationship is different. The differing terms are not always front and foremost in the user’s mind. Divergent expectations arise, especially when barriers to entering the relationship are low.
Apps are low-cost consumable products to be sold, not ongoing customer relationships to be honoured. App stores mediate customer relations. Customer relationships belong first and foremost to the App store vendor, not the developer. Maybe this explains (1) above.
To me at least, software tools are not throw-away items, they are things you live and work with every day. They become part of your routine. Something like an email client is an intimate part of your world. It’s something you form a relationship with. You invest time becoming accustomed to it. Shouldn’t the custodians of the App take this into account? If not, why not?
How much transparency within the developer-user relationship is possible? How much should be expected? Personally I would prefer to buy software from a developer who is in business to serve the customer, not just to create intuitive and pleasurable experiences for the highest bidder. I don’t think I’m alone.
[Edited July 22: minor edits and cleanups]
