The whole article makes for some pretty depressing reading, and touches upon some important points. For me, the most crucial and eye opening is the stark contrast of the relatively open ecosystem we had back in 2005 to what we have today. You can't help but feel uncomfortable about the whole direction we're taking with tightly controlled silos of information (Twitter, Facebook, G+, etc.) using extremely limited, or highly monetized, API access, when you read something like this:
"One thing that’s definitely coming (and some of these already exist, although haven’t yet been made public) is extremely deep API support. Our general plan here is to expose nearly everything in NewsGator Online via API, and allow folks to build applications that leverage our platform in unique ways."
Google is just as guilty as several other parties of bringing about the situation we have now. I get the fact that everyone is looking for ways of increasing revenue, but they're doing it at the expense of openness, instead of leveraging that openness (see RSS for example) and building services and added value on top of it.
I hope the death of Reader serves as a wake up call on several fronts.
I saw this situation coming a long while ago. These companies are now turning against those who made them what thu are. Worst is that they turned against us, the hackers. No or limited API access, real name policies, lack of gener privacy, no way to get your data back, etc. All of this as a result of these companies being run by the traditional corporate drone. This is why Nuuton is being developed, by me, a hacker with business experience. I know how the value Of a company depends by the hacker community that forms around it. When I say value I don't mean money. I mean how well the company is poised to do some re innovation and provide a good dependable service to the community at large.
Nuuton features a strict privacy policy with no re names, no tracking, no bubbles, and private data as a default. It will also allow for easy access to your data. All of it. To the hacker community, it has and will have a robust collection of APIs for you to use without draconian limitations. Best of all, Nuuton is not being developed as a one way lottery ticket. I don't need or want the money. I'm building it because I have had it up to here with dealing with these abusive companies.
I hope what you're building is open source and resides 100% on the client's machine. Because if it's closed source or makes use of your servers, then it can't be trusted, no matter what lofty rhetoric you use to advertise it.
The fact is that if it makes use of your servers, you have the power to spy on the people using your service. You may claim that you won't, and provide a lovely privacy policy, but there's no way for the users to make sure you're actually adhering to those policies. Then it comes down to trust, and some of us don't have a lot of trust left.
This is why I use client-based, open source RSS readers like Newsbeuter,[1] and will not be moving to any web-based reader, no matter what features they have or how concerned they claim to be about privacy.
That said, if I had to use a web-based service, I'd much rather use one that claimed to have a commitment to privacy than one that didn't. So kudos to you for that.
I reason there is a middle ground. The aim is to, at the very least, get hackers to start thinking about privacy and about building systems that are beneficial to society whe respecting the rights of those who use them. I am using open source software, and I am releasing the code when it reaches a point where it can be useful (as django apps/python packages and Lisp libraries). The ALPHA and beta versions f the system (will) reside on my servers until the de-coupled design is completed. Because the real beauty about Nuuton is that is simply a loosely coupled system built on top of a collection of APIs. The client drives all of the logic and simpy send/receive encrypted data. All data on Nuuton is encrypted. All of it. So, at the ALPHA level it will not be completely open as you state. But it will respect your privacy and will be open to audit to researchers. I believe in privacy and am building a system that respects it.
I had never talked about the system itself, but its about to hit early ALPHA. Keep posted for the announcement. Note that those who signed in as ALPHA users get a hacker account with access to the first APIs.
I'm pretty sure this project will not become huge. But it will get a of us thinking about making more open systems.
Based on what you've written here, I'm very interested in what you are talking about. However, what I can't understand is why you would choose to go-it-alone, when other projects are looking to do the same thing. Namely, buddycloud.org and tent.io.
The open source world seems to get so fractured, even among projects that seem to be aiming at solving the same problem, that none ever gain enough traction to reach the goal with any kind of success.
I wish you luck on your project, but I hope you will look at those that have existed before yours (e.g. Diaspora), and those that are taking a new approach (mentioned above).
I appreciate the nice gesture. I do know about these other projects, and do consider them as allies. But I believe that the more projects we have like these coming out, the more improvements will there be made as whole.
One of the issues in the multi-device world is that you want to have some kind of sync across those devices. From what I can gather, this was one of the most useful features of using Reader as the backend and I can't see how to replicate it without having some kind of central server.
This is a more general problem and (I believe) it will become more important in the coming years.
I don't see why an RSS app that resides 100% on a mobile device couldn't sync directly with another RSS app that resides 100% on your home computer or your work computer. No external RSS service necessary.
That said, I understand that sometimes externally controlled and centralized services can provide features and convenience at the expense of user control and privacy.
I care enough about my privacy, and aware enough of the alternatives to choose to tend to choose privacy over features and convenience (when I'm faced with such a choice).
I know a lot of users don't care about their privacy, don't realize how loss of privacy could impact them, or don't know that there are alternatives. So they often choose to use "free" web services that give them some features or convenience (or just because all their friends use it, etc.).
This is unfortunate, but hopefully as more people become computer literate, the media exposes more cases of privacy violations, and more people become victims of identity theft, internet stalking, harrassment, and discrimination based on their computer and internet use habits, they'll start to wisen up and care more about privacy.
I also care about privacy and data ownership [1] but the specific issue I was getting at is the 'always-on, always-connected' feature of cloud services (regardless of whether they're under your control or not).
> "I don't see why an RSS app that resides 100% on a mobile device couldn't sync directly with another RSS app that resides 100% on your home computer or your work computer. No external RSS service necessary."
How would my phone know what I'd read on my computer if I'd already left the house? Of course, it's possible in principle but wouldn't some form of cloud-based co-ordination be necessary in order to make the experience seamless for a user? I'd be keen to know if there's something I've overlooked here.
[1] I'm working on a set of projects related to it - http://perscon.net (site needs updating but there's enough to give you an idea)
"How would my phone know what I'd read on my computer if I'd already left the house?"
Your phone could just contact your home computer via IP address (or maybe domain name, dynamic or otherwise) your home computer has. Your home computer would, of course, need to be on at the time your phone tries to connect to it (and vice versa).
Another option is to use an intermediary server under your control, like perhaps a VPS host that you'd run some syncing software on, and have both the phone and your home computer sync to that. That way, only the VPS and the machine/phone you're syncing from would need to be on at a time (ie. both your phone and home computer wouldn't need to be on at the same time, if that was a problem for you).
Thanks for explaining and we're actually on the same page. Working on things to make both of those options easier for devs/users (end-to-end connections and personal VPNs).
Hopefully will have things worth showing off later in the year.
That is a very good point. It used to be that you had to keep your computer on to serve as your own cloud. If your electricity prices were high, this didn't make sense.
But now, the smartphone is the always-on computer. And it uses minimal power -- possibly even less power than cloud computing, which is deliberately oversized in order to handle peak loads.
I suspect it's too complicated for non-geeks to figure out, though. There are also certain drawbacks-- for example, your phone has real storage limits, while the cloud can expand without user intervention.
"run by the traditional corporate drone": Would that be Eric Schmidt, who got a Ph.D. from Berkeley in EECS and co-wrote lex ? Or Larry Page, who left Stanford's graduate degree program to be an entrepreneur in 1998?
If Nuuton is worth anybody's attention, you won't need to lower yourself to this kind of post.
> These companies are now turning against those who made them what thu are. Worst is that they turned against us, the hackers.
All your examples are in the past, except for Takeout, and I would no more put much money on that surviving in a full-strength form (if at all) for the next 10 years than I would Blogger or Keep staying up and active.
Not rolling back some changes they made long ago is not very impressive a defense.
> Larry Page is still the current CEO of Google.
'Still'? Schmidt was CEO for a large chunk of Google's existence. And yes, Page does seem to be the problem. I'm reading _In The Plex_ now, and maybe it's just me projecting, but Page seems to come off as a autistic asshole with problems and the book speculates it's related to his father's death.
I'm unsure what your point is. philsnow pointed out that both Schmidt and Page are not your typical corporate drones (they have serious technical contributions as individuals), and your response is that it was Schmidt and not Page who was CEO for much of Google's existence?
I was pointing out that 'still' seemed to involve a misapprehension.
And your comment completely ignores my first point that not actively dismantling past good contributions is very far from demonstrating that they are not turning against hackers.
But Twitter doesn't make any money, and Facebook not that much. The bulk of Google's revenue comes from leveraging the openness of the Web; were there only Facebooks and Twitters there would be no Google Search because there would be nothing to index.
This may be completely off, but the killing of Reader looks like a desperate move to help Google+: since Google can't kill Facebook, they're willing to hurt themselves instead -- to cut their left arm so that their right arm can grow stronger.
If this is indeed the case, it's very shortsighted.
"The bulk of Google's revenue comes from leveraging the openness of the Web"
Does not compute. Google makes its money selling ads. Those ads appear mainly on Google's website, which is very much closed. Nobody knows how Google comes up with search results and why specific ads are shown.
"were there only Facebooks and Twitters there would be no Google Search because there would be nothing to index."
Google existed before social media: before Myspace, before Friendster, even before LiveJournal. When Google started, 'blog' wasn't even a word and Geocities was one of the most popular sites on the web. Social media is still a small part of what happens on the web. But imagine, were there only Facebooks and Twitters, surely Google would be offering ads there.
If it's displayed on a networked computer, it can be indexed – Facebook and Twitter can be indexed, it just takes more effort. But let's imagine there would be no way for Google to index the web, then they would find other places to put their ads. Google is an advertising company, not an Internet search company.
> Google is an advertising company, not an Internet search company.
I would avoid defining a company by its current monetization strategy especially in an industry where monetization is frequently an afterthought (it was for Google).
Furthermore, it doesn't do much to define a company since there are only so many monetization strategies.
What if we'd start defining companies by whether they are "for-profit" or "non-profit" instead? We'd end up with such non sense as "Google is a for-profit company, not an Internet search company." Or with, "B2B" vs "B2C": "Google is a B2B company, not an Internet search company."
If you are going to pick only one thing that defines a company, at least pick something that really makes them stand out (Google - search, Apple - consumer electronics, Facebook - social networking, etc.).
This may be true, but I think you are turning the discussion in another direction.
The talk here is of Google's current/primary business model. It is, in fact, based on the open Web as was stated previously.
Sure, they could buy other properties. But that just implies a changing business model (ex: content destinations). For that matter you could extend the argument and say that they might buy Facebook or Twitter.
But the need for them to buy such destinations in order to continue their advertising business actually itself speaks to the closing of the Web.
I guess OP meant that if you could see only a part of the web available to you as a logged in user of some service, then you couldn't build an index which globally scans a whole website, since it cannot log in.
NOTE: well spiders could technically log in and index public shared stuff, but those services could forbid that via terms and conditions and sue any company violating them
> Google is an advertising company, not an Internet search company.
Those were perhaps the good old days. Today's Google makes less and less from ads and more from big data i.e., spying and selling (and trading) ever more extensive information about individuals, business entities, governments and other organizations. This is where the New Google (post "don't be evil") is competing Any service or app that doesn't return it's investment in PII (Personally Identifiable Information), Corporate Espionage (as it used to be called before there was Big Data) or state secrets is at best a loss leader.
Twitter does make money on its API. It's done through channel partnerships. Is it as much as advertising? No. But still significant.
Twitter's API is still sufficiently open. There's plenty of data to be had. The limitations and constraints breeds creativity, and we'll finally see new integrations and ideas that do something new rather than simple enhancements and user-annoyance-fixing-as-a-product.
Except Twitter used to offer "extremely deep API support...allow[ing] folks to build applications that leverage [their] platform in unique ways." And then they couldn't make any money that way.
I'm really not sure you have a good example of a loss of an open ecosystem here. NewsGator's plans were to pretty much create the equivalent of the (unofficial) Google Reader API, which, while not replacing RSS (the actual open format), does notably reduce its role. Moreover, for those who apparently don't remember, NewsGator actually did release their API. The API and their free reader software is what they shut down in 2009.
You can blame that on Google, who did indeed retain the lion's share of users, or you could blame the self defeating business plan of providing a completely open API for free even while it costs money to run. A NewsGator API is not a loss in terms of a loss of an open ecosystem (and Bloglines was definitely not a loss).
If you want open, you need a real federated protocol. Like RSS.
Meanwhile, this article says "RSS industry" in the headline, but it's about nothing like that. The author says it himself: "No, Google Reader’s real competition back in its early days was not client software but services that aggregated RSS feeds and synchronized them across multiple devices."
You can't embrace, extend, and extinguish services that have no standard format. RSS is doing just fine. What was lost here was a UI and a service, which leaves us with user migration pain and a loss of continuity of history (due to indefinite feed history).
We'll likely always need some services. Yes, I can run a feed aggregator on my home machine, but it's kind of a waste, and not everyone has stable IP addresses they can use to sync across devices. Instead of giving up on services, what we need to learn from this is to make sure the next services we allow ourselves to depend on don't have control of our history, both individually and collectively. Notably Facebook, Twitter, and G+ don't fit this bill, or fit it only partially.
(Unfortunately, our collective history on those services is complicated by visibility/access by person controls, so maybe there isn't a perfect solution. I know I can use takeout to download my posts on G+, for instance, but what about my comments on others' posts, and what about those posts themselves as context for my comments? And what about the major news of the day, even if I didn't comment?
It certainly can be, but it's not an open ecosystem. I hate when discussions dissolve into arguments over "open" just because the participants didn't have the same definition for the word "open" to start with, so I probably should have been more careful with using it. I was really just using it in direct reference to the OP's post, trying to say that "the relatively open ecosystem we had back in 2005" wasn't really that, at least in this context.
If an API is the sole source of a service, and, even worse, if it's the sole source to access data that users put into a system (e.g. feed history for essentially all feeds, facebook posts, etc), you're totally dependent on that API making enough money to justify its existence based on the whims of the people who make that decision. Luckily there's google takeout this time, but some data is still being lost. One benefit of usenet was that everyone could have a copy of everything, though there's many privacy tradeoffs there (in the modern social networking sense).
Anyway, it's not really a novel argument, just the same "dangers of monoculture/single-point-of-failure" point that has been made many times.
I could change my post to say the didn't make any money that way, but the point is the same. The problem is access to a user's content being at the mercy of revenue. An API from a single vendor that has to be paid for is not a type of open ecosystem and 2005 was not a magic time of possibilities that have since died.
In the word processing space, the cost to switch providers is much higher because unlike in the rss space, the average user isn't usually technically inclined. It is why MSword persists as a huge market leader, even after its ribbon interface turned it into crap, and there were competitive FOSS alternatives to a hundred dollar purchase price.
Google docs as a consumer use case isn't bad - hopefully you have the brain to know how to get all your drive content and switch when they eventually kill Google Docs as not profitable enough.
The problem is the business use case - and this comes from the popularity in the consumer space. The collaberative features of docs/drive is even more applicable in a workplace environment, and if businesses that hire "less technically inclined" people and have to hand hold them into getting used to it, and are presented with a demand to switch, the transition overhead would be massive.
It is actually a strong business interest to use FOSS because I bet it would cost less to get a junior developer to manage a fork of an old interface / feature that was depreciated in mainline and keep the security up to date than it would cost an actually big business to switch their entire software suite away from a depreciated closed product / one that radically shifts.
It isn't about ribbon being inherently good or bad, it is how it required the retraining of dumb office staff that could barely hit the power on button of an office PC if it turned off. If you are using closed software and that kind of thing happens, either you try to hold on to an outdated unsupported version or pay the overhead of transitioning your staff to a new interface.
From a business perspective, especially in large corporate environments where the majority of your workforce is often mediocre, absolutely. It is wildly expensive to switch tech. It is why Microsoft has done so well with Windows for 20 years, businesses get on the purple dragon and Microsoft juggles keeping everything supported to keep them happy and unchanging.
"One thing that’s definitely coming (and some of these already exist, although haven’t yet been made public) is extremely deep API support. Our general plan here is to expose nearly everything in NewsGator Online via API, and allow folks to build applications that leverage our platform in unique ways."
Google is just as guilty as several other parties of bringing about the situation we have now. I get the fact that everyone is looking for ways of increasing revenue, but they're doing it at the expense of openness, instead of leveraging that openness (see RSS for example) and building services and added value on top of it.
I hope the death of Reader serves as a wake up call on several fronts.