ProgrammableWeb Blog

Good point.

It's fun to do the popular comparison of Twitter vs. Facebook as well.

It's interesting to note that in terms of revenue, Facebook is pulling in around $5/user/year right now. But their valuation per user is around $114-$143 (currently $80-100 billion).

http://news.ycombinator.com/item?id=2969934

FB claims 700+million users, with 600million active.

Twitter claims 175million users but going by your metrics a much lower percentage are active.[1]

Given these numbers and a common metric of valuation over 5 years (and the assumption of no more user growth...I know it's not realistic but it makes the math easy), FB has to figure out how to multiply $25/user (over 5 years) by 4 to 6.

Twitter has a much steeper hill to climb to justify their valuation. Not only do they have less information about a user (so targeting advertising is harder), but FB has other methods of revenuing a user, online apps, games, etc. Twitter hasn't even proposed a revenue model outside of limited, randomly sampled, access to global tweet streams (which are likely not a major revenue driver in anybody's business plan) and recently announced paid forced tweets just showing up in people's streams (which I'm sure will go over well sarcasm).

To make matters worse, their experience doesn't really require people to come to their website. And it appears most activity is not via the site, so embedded adverts are going to be very hard.[2]

I can't figure out the math on this to be honest. Hell, I…

I don't think that long-term I'd want any client-code speaking directly to the backend over a generic API. It's far more optimized to migrate to code that sends fewer requests with as little traffic as possible over the wire, and often that means knowing state both on the server and client, which isn't all that RESTful. http://blog.programmableweb.com/2012/05/15/why-rest-keeps-me-up-at-night/

The point is the different design goals: Yes, you can send page after page of HTML, refreshing content that hasn't changed. But we moved to AJAX because that was inefficient. Better to have the browser ask for just the data it needed. Well, efficiency will then lead to either better protocols to bundle up multiple requests or the simpler approach of bundling up data into one request designed for that particular user's session. Hard to put RESTful, meaningful unique IDs on that one.

Of course, the risk you run is one I've frequently encountered in Google Music, for instance. The state graph is messed up somehow and duplicate data or corrupt data starts appearing in the JSON stream to the browser and in the UI. Not much you can do except refresh, logout, or wait for a code update to clear such caches, unfortunately. That can be the downside to "smarter" clients and why even today we have cache clearing and a "force-reload" action.

This is also why automated backend services should use REST for simplicity, and why UIs need to be built to consider network traffic, re-sending failed…

Certification would more to do with proving an identity, a physical address, a bank account and being connected to real people. It's to make it more difficult for would-be scammers from being able to hide. Thus, a publically accessible website of who's raising money, for what, their photo, and some references who've vouched for this person would (I think and hope) significantly deter scammy behaviour. (of note, this type of information is becoming more accessible anyhow http://blog.programmableweb.com/2010/09/20/watch-out-for-stealthmodewatch - stealthmodewatch.com)

On the other side of the coin, investors could take a simple multi-choice test on ROI, accounting and finance principles .. whatever.

I'd have to brainstorm further. If an arm has a problem, you don't cut it off, you fix it and make sure it doesn't happen again with creative solutions - because you're not solving any problem by amputating (or rather not applying that solution correctly if there are healthier alternatives), you're just creating more problems.

-- another solution may be to simply cap investments at a certain amount, so people can't invest their life-savings in one go.

-- also, a way to search on these micro investments (and micro investors too) would be great: http://www.google.com/finance/stockscreener http://www.formds.com/filings (hat tip gojomo)

This is more awesome than it first appears.

They are a SaaS "Create Once, Publish Everywhere" (COPE) provider. NPR popularized the term a few years back, and the use it in their production environment. I have one client actively using the same architecture in production, and they love it. They use a Django site as the backend, and node.js-powered websites to publish the content.

Some links on the topic:

http://blog.programmableweb.com/2009/10/13/cope-create-once-publish-everywhere/

http://www.linkedin.com/groups/Do-you-COPE-Create-Once-3912082.S.117059484

http://www.slideshare.net/KMcGrane/adapting-ourselves-to-adaptive-content-12133365

http://karenmcgrane.com/2012/09/04/adapting-ourselves-to-adaptive-content-video-slides-and-transcript-oh-my/

http://www.markboulton.co.uk/journal/adaptive_content_management

http://meetcontent.com/blog/structured-content-an-overview/

One of the uphill battles they face is the nomenclature. Most people couple their content creation tools with the publishing tools. I.e., we think of a CMS as both the editor and the content renderer. This sort of system decouples that.

I think they are smart starting with a PHP library: that seems to target a broad install base, and publishing in PHP using an API is much easier than building a solid CMS in PHP.

While I hate to blindly agree and lump all these successful companies into API traps, you are pretty much right. From a business standpoint, if Facebook (or any other API company) sees massive growth/activity in an application on its platform, you better believe they are going to take notice and have some course of action.

You can even throw LinkedIn into this group (http://blog.programmableweb.com/2012/06/21/linkedin-shuts-down-headhunting-app-how-open-is-open/).

The main aggravation/issue stems from developers wanting to use these APIs to gain access to users without fully qualifying the risks. I could easily be building a fantasy sports app on Facebook thinking, "they won't EVER get into this market. They have much bigger problems to solve." 2 years later, they get into the space and shut me down because I am a competitor.

These "wannabe collaborators" are not trying to improve the experience on said platform. They are trying to gain access to a vast database of users with low barriers of entry and an easy to use(/abuse) marketing channels. It's unfortunate that no one has the foresight into understanding where a company as large as Facebook/LinkedIn/etc may pivot into, but only insiders really have first hand knowledge of this sort of thing.

Awesome job man!

Ease of use requests for the star chart page:

1. GeoIP db to get current location
2. Autofill location
3. autofill date
4. autofill local time

GEO IP: http://blog.programmableweb.com/2009/03/31/3-free-ways-to-geolocate-by-ip/

Viral ideas:

1. Allow creation of star charts from FB data (eg. City / DOB)
2. Add FB share link.
3. People buy star charts for friends

It pains me that people believe in this psuedo-science, but will make you money ideas:

1. Allow some kind of astrological star chart that is
tangentially related to their astrological sign.
2. Pair with FB (eg. Fred's Libra Starchart)

Btw, yesterday was my birthday and if I could have posted this on my wall it would have been awesome. (Not the astrology part)