Your App Is Not Better than an Open Protocol • Hacker News Board

Re: Your App Is Not Better than an Open Protocol

#111

Post by freshyill » Thu, Feb 19, 2015, 7:20 PM UTC

illicium wrote: post #101

freshyill wrote: post #95

> When Twitter was gathering steam back in 2009-10, it did so because tweeting was done via SMS and not over a proprietary interface. I don't believe this for a second. In 2009-2010, there were already a huge number of smartphones and Twitter clients out there. In fact, that time was probably better for third-party Twitter clients than today. Smartphone growth exploded in 2009-2010, so the idea that "everyone was get…

Don't forget about Twitter's API and liberal usage policy that made the plethora of clients and mashups possible -- I think this accelerated their growth more than anything. Their API is not so "free" now -- you need to register your app, always authenticate, and there's no public firehose access any more.

You're correct. Smartphone usage growth basically coincides with Twitter's growth, and early Twitter apps had far fewer constraints.

Twitterrific was a jailbreak app before Apple even launched the App Store. Did Twitter even have an official iOS app before they bought Tweetie? That seemed like it happened around the time of the first big API lockdown.

Re: Your App Is Not Better than an Open Protocol

#112

Post by alxndr » Thu, Feb 19, 2015, 7:20 PM UTC

mtbcoder wrote: post #59

matthewmacleod wrote: post #26

Earlier quoted context omitted.

I don't think it's fair to describe that as greed. The fact that a business can't monetise a service it provides is a bad thing; if Twitter for example provided access to everything over an RSS feed, the first thing you'd see would be applications that simply stripped or refused to display advertising etc. I don't see why it 'exploits the common good' to want to charge or monetise a service you provide.

In the past, Twitter did provide RSS feeds of your status updates.

One of my favorite features of the RSS reader I use is that it can hook up to a Twitter list, effectively giving me back an RSS feed of tweets.

(Previously I'd been scraping together Yahoo Pipes or Google App Engine based things people had made, each of which would work for about six months before something finicky would break 'em...)

Re: Your App Is Not Better than an Open Protocol

#113

Post by ChikkaChiChi » Thu, Feb 19, 2015, 7:23 PM UTC

First:

"Open protocols power the web...RSS, SMS, plaintext-email, HTML5 - these are the easiest, fastest ways to get users into your system."

Then: "Flipboard just announced their migration to full-canvas"

Unless we have different understandings of what HTML5 is, I think you just invalidated your own point.

Re: Your App Is Not Better than an Open Protocol

#114

Post by api » Thu, Feb 19, 2015, 7:32 PM UTC

mkagenius wrote: post #100

api wrote: post #89

People don't pay for open protocols.

The aim should be to use protocols as a tool rather than direct source of revenue.

That's not what I mean. What I mean is that given two products -- one with an open protocol and one with closed -- very, very few customers will exercise a buying preference for the former.

Re: Your App Is Not Better than an Open Protocol

#115

Post by sanderjd » Thu, Feb 19, 2015, 7:46 PM UTC

mangecoeur wrote: post #78

TeMPOraL wrote: post #23

Earlier quoted context omitted.

The moment such business stops being "idealistic" and makes that "logical step" is the moment it stops caring about providing value for customer - it reduces the value provided to monetize them better.

Well the saying goes - if you aren't paying for it, then you are the product, not the consumer. People using twitter or google or facebook are not clients because they aren't paying. The clients are the people who pay those companies for valuable information and advertising space.

Just a nit-pick: "you are the product, not the customer". I think a "consumer" can be either. Further complicating the terminology, many sites where you're the product (and some where you're the customer) rely on you to actually be a producer of content as well.

Re: Your App Is Not Better than an Open Protocol

#116

Post by O____________O » Thu, Feb 19, 2015, 8:59 PM UTC

pdonis wrote: post #96

O____________O wrote: post #91

Earlier quoted context omitted.

He indicated that the law would limit a company to N employees. The stated goal was to benefit the greater good, but the metric was simply a number.

And how do you decide what N is?

Not my problem. I'm only pointing out that the parent comment asked a question that implied a misunderstanding of GP.

Re: Your App Is Not Better than an Open Protocol

#117

Post by jackmaney » Thu, Feb 19, 2015, 9:39 PM UTC

amelius wrote: post #103

jackmaney wrote: post #81

Earlier quoted context omitted.

That's assuming that Search Ad Services by Google will have--or will be allowed to have--clients other than Google. And that, of course, is the entire point: to split a company up into what are technically smaller companies that, in effect, are just part of the head company.

Of course a company cannot be selective about its customers in a way that is anti competitive.

Ummm...yes. Yes, they can.

Re: Your App Is Not Better than an Open Protocol

#118

Post by sangnoir » Thu, Feb 19, 2015, 9:51 PM UTC

mangecoeur wrote: post #78

TeMPOraL wrote: post #23

Earlier quoted context omitted.

The moment such business stops being "idealistic" and makes that "logical step" is the moment it stops caring about providing value for customer - it reduces the value provided to monetize them better.

Well the saying goes - if you aren't paying for it, then you are the product, not the consumer. People using twitter or google or facebook are not clients because they aren't paying. The clients are the people who pay those companies for valuable information and advertising space.

The saying is full of crock - it presents a false dichotomy. You might pay and still be a product. You pay for cable TV but they sell you to advertisers.

Re: Your App Is Not Better than an Open Protocol

#119

Post by xg15 » Thu, Feb 19, 2015, 10:05 PM UTC

Retric wrote: post #58

TeMPOraL wrote: post #50

Earlier quoted context omitted.

While their plug can be defended on engineering grounds, I'd ask a different question - why lock down Bluetooth to Apple devices only? iPhones were perfectly able to exchange data with non-Apple devices until at some point they weren't.

You can still use iPhones with car's built in systems so it's not really Apple only. If you mean accessories like wireless keyboards I think the same 'just works' arguments directly apply. There are lot's of terrable 3rd party products out there.

Of you redefine "just works" as "just works if you own a product from our carefully curated list of authorized accessories", then yes...

Re: Your App Is Not Better than an Open Protocol

#120

Post by zanny » Thu, Feb 19, 2015, 10:10 PM UTC

coldcode wrote: post #64

ebbv wrote: post #8

Earlier quoted context omitted.

That's clearly not what the author is saying. You can easily create something new while embracing standards. You can open your app up to existing standard means of consumption like RSS, email, SMS, etc.

So how do standards come about? Someone does something new. Which means it isn't a standard yet. Otherwise we would still be using 1980's technology "standards".

There are very discrete routes to standardization through the IETF, ISO, ANSI, etc - you submit proposals, get them vetted, etc.

Two examples would be HLS and DASH. HLS is a draft standard of the IETF proposed by Apple, but Apple has never pursued standardization beyond that. This effectively means Apple maintains complete control of HLS and can change it however they want while still passing it off as a pseudo-standard. DASH was made by MPEG-LA, mainly to continue forcing their patent ridden nightmare video codec down everyones throats, but they got through full ISO standardization.

The third wheel there would be Flash - not a standard at all, a proprietary streaming protocol that is only usable by Adobe. They have no intent to standardize, and no intent to open the tech up ever. That is the kind of vendor lock in the OP talks about. All three were "something new", but each one did something different. And when you are making a product, you could take explicit steps to document your protocols and architecture, or you could keep it all proprietary and user hostile and try to maintain maximal control of everything.

Another good example is messaging. XMPP is another IETF standard, Telegram is a proprietary server with an open protocol, while Skype, iChat, Hangouts, and Whatsapp are wholly proprietary. You can implement XMPP servers or clients, and clients and servers can interoperate (assuming the server lets you, Facebook uses XMPP but their server isn't a full implementation, so you cannot add non-facebook friends in the service, for example). Telegram lets you implement clients however you want, but the protocol is designed to only work with their messaging servers, so you would have to fork the protocol to have server independence from Telegram. The others are all black box protocols nobody else can interoperate with and have no documentation.