diego's weblog

there and back again

Category Archives: ning

dreaming it all up again

“It’s no big deal, it’s just — we have to go away and … and dream it all up again.”
 U2 at the Point Depot, Dublin, December 30, 1989
Today was my last day at Ning.

Seven years ago, almost to the day, I wrote on my weblog about looking for the next big thing, after clevercactus, my previous startup, ran out of funding. I had spent all the money I had pursuing an idea, to the point that for a few days in early December 2004 I couldn’t buy food (I eventually got a contracting job that tied me over for a bit), but I didn’t regret it. More to the point: I was exhausted and more than a little burned out, and I couldn’t really see clearly what I wanted to do next…. except move back to the Valley, and to take on a new challenge.

The response was amazing — many people, most of whom I didn’t know, emailed me to offer advice, help, and some of them, opportunities.

One of those emails was from one Marc Andreessen. I met him, and Gina at their small office (at that time the company was still called 24hourlaundry, “meeting absolutely none of your laundry needs”) in Palo Alto. After five meetings (!) they made an offer and I accepted it “in principle” without even knowing exactly what the idea was –it was that much in stealth mode– and we agreed that if I didn’t like the idea, once they described it in detail, I could say no. Now, it may sound crazy to accept an offer sight-unseen, but I’ve always valued teams more than anything and we had had a great time talking about ideas, the state of the market, and what social could be if it was really pervasive (remember, this was late ’04/early ’05).
I had to go back to Dublin, so we arranged to do a web meeting to go over the idea.

We set up the call, and the first slide went up. No fancy graphics, no eye-catching copy. It just said:

     A web platform for social applications

Holy shit, I thought.

I got it, instantly.

I didn’t hesitate. Before Gina could start talking, I said “where do I sign?”

And that’s where Ning started for me.


I got working on it immediately, on the first piece of the system we needed to boot up the environment, the administrative interface.  Funnily enough that interface is basically the one piece of code that still runs relatively unchanged to this day.

What followed was an incredible journey. I became Chief Architect, then VP of Engineering, then CTO, taking the job over from Marc. Throughout all this, we grew from 20 people or so in 2007 to over 120 in 2008, from 100K users in early ’07 to 1MM users in December that year, to 10MM users in December ’08, and beyond that.

We went through a couple of years of people telling us things like “a platform for social networks? Well, I can build that in PHP in a week, why would anyone want that?” until it somehow became obvious that people would want just that (and that no, you couldn’t build it in a week), and they would even (gasp!) pay for it. In 2009/2010, acting Chief Product Officer as well as CTO, we designed a new product offering and business model, and then I focused (with just a couple of brilliant engineers) on creating a new mobile product from scratch, Mogwee.

Today, just like two years ago, Ning networks register millions of users a month, and have reached people everywhere, even if they don’t know it. A lot of them do know it, though — I’ve met a lot of people that have told me that Ning changed their life, and I can’t even begin to explain how it is that they have actually changed mine.

When Glam Media acquired Ning in September, I decided that it was a good time to start something new. Glam+Ning have great stuff coming up and I look forward to seeing it unveiled in the coming weeks and months, but the itch to go back to being a Pirate was something I just couldn’t ignore :-).

So, here I am.

I am deeply grateful to Marc and Gina for giving me the opportunity early on to be a part of something amazing, and to the many, many people that contributed to make Ning what it is today, including its Network Creators, who are the most committed user community I’ve had the privilege of working for.

I’ll be starting something new, and I’ll certainly be blogging more over the next few weeks. In theory, I will even be taking time off over the next week or two, but who knows how that’s going to pan out. (A friend said, “Yeah, I can see you taking one or two… days off.” Heh).

 And that’s it for now. All I need is some time to…  dream it all up again.

graphs aren’t social

At Ning, we often hear the following question from people outside the company: how do we see the ‘social graph’ from our perspective?

They don’t ask what people enjoy doing on the service. They don’t ask for stories of users, of finding long-lost friends, or of newfound friendships. They don’t ask what makes people on Ning join ten different social networks, as they often do, even if this flies in the face of conventional wisdom about how people are sick of joining social networks.

No. They ask about the social graph.

I am honestly amazed at this question — is that really what they care about? An abstraction? I am amazed, and at the same time I understand where they are coming from.

When I started at what would become Ning some three and a half years ago, I had spent a few years thinking about social networks, ad hoc group formation, and self-organization. I was completely immersed in the terminology with which we try to make sense of phenomena that is sometimes hard to grasp at an intuitive level. Groups of people are not just the sum of the individuals that compose them, and this creates a chasm that is hard to cross–for we, as individuals, project out of ourselves and into the world when we look for answers.

What I hear when I listen to someone talk about the social graph, what I think of when I read about the social graph as if it was a real, tangible thing –in fact the only real and tangible thing–, is a mathematician, talking to someone proudly showing off her new car, pointing at a wheel and asking: “how’s that circumference working out for you?”

The notion of a circle, how it is unequivocally described, what its characteristics are, is undeniably of great value to anyone interested in mathematics or geometry, and even to anyone interested in designing a car or producing a wheel. And it is of no value to that same person when using a car. Not in the mechanics of the action, mind you, in which the device is at work, but in the actual use, and even enjoyment of what the abstraction, applied to something real, can do.
Likewise, the notion of a social graph is interesting to us in nerd-dom as part of our continued understanding of what it is that we’re actually doing, but it holds almost no sway in determining whether something has value for people.

Hundreds of social networks have come and gone. They all had ‘social graphs’ as a key part of their functionality. If this mythical graph is of such importance, why, then, did so many of them fail?

A thousand factors, to be sure, but one of the most important surely must be that they didn’t connect, in some meaningful way, people to each other, and to the service.

I choose words carefully when I say people and not users. Semantics matters. It’s easy to fall into abstractions to handle numbers or notions that seem too big to grasp, but we should resist the temptation. Because it’s when we start designing our software for abstractions, rather than for people, that things go off-course.

Don’t get me wrong — I live and die with abstractions. You will have to take my little diagrams and sourcetrees and formulas and tools from my cold, dead hands. But these are the things I build software with, not for. And that’s how it should be.

We must see past the abstractions and speak to what people really use, and crave, and communicate with. Let’s use the abstractions and obsess over them, but then translate that into something real and meaningful.

Graphs aren’t social. They’re just graphs.

And we should never lose sight of that.

ning news: fast company article, new round, new releases

A few Ning networks, viewed as graphs

A couple of Ning-related news/articles hit the interwebs in the last couple of days — first, there was a Fast Company article, Ning’s Infinite Ambition, that covered viral loops and what is behind a lot of the recent high-growth Internet sites, and it’s definitely worth a read.

Then today VentureBeat broke the news of our recent investment round. Marc has more details. As he says, VentureBeat found a mandatory SEC filing and put out news that we’d otherwise not have talked about, since there isn’t a clear reason to be doing it. The reasons for the round, as Marc says:

We raised the money to enable us to keep scaling given our accelerating growth (over 230,000 networks on Ning now, growing at over 1,000 per day) and to make sure we have plenty of firepower to survive the oncoming nuclear winter. At current growth rates, we don’t need it to get to cash flow positive, but having lived through the last crunch, it’s good to be conservative with these things.

Meanwhile, the rolling train of releases continues apace — most recently with Events and Notes, two features that were very well received. It’s really great to see the instant reaction from users as they give instant feedback on both the good and the bad. Meanwhile, the Developer Network keeps growing, with a recent reorganization of docs to improve navigation — we’ll be doing a lot more that in the coming months, as we have been in the past months.

A lot done, still more to do. 🙂

opensocial: not just about one company

Dave comments a bit on OpenSocial, and mentions his concern about Google keeping data locked up. Marc Canter points out (correctly) that user account data would remain on each social network (‘container’) that implements opensocial.
I’d go a bit further to point out that very little about this announcement is about open data or not open data. I happen to agree with Dave (and Marc) that data should be open. Just to be clear, I’m not just saying this: at Ning, we’ve been open on that front (if not great about documenting it fully :)) from day one. Today, you can easily cook up a script to take your personal data and take it with you, re-analyze it, do whatever you want. It’s your data after all. Part of the reason we could implement OpenSocial support so quickly is due to the fact that Ning is at the core a very large set of XML/JSON APIs — the benefits of being open are not always obvious, but this is definitely one of them.

I think Dave was focused on the Data aspects because prior (incorrect) rumors about this announcement implied that Google was going to announce something to gather data from multiple social networks.

But I digress. What I wanted to add to the conversation was that Dave put a quote in there that struck me for how well it applies to OpenSocial.


How much happier we would be if instead of crippling each other with fear, we competed to empower each others’ creativity.

And that’s what OpenSocial is about, at the core–regardless of whether that was the intention all along or not, that’s what it’s become. A set of common APIs in Javascript, using HTML for display and XML for component wrapping that everyone supports in the same way, with all the benefits that entails.

OpenSocial is much less about Google v. Facebook than the announcement makes it seem. Everyone focuses on the Facebook angle, but if Google just wanted to take on Facebook, they could have done that, no? Is the Facebook thing a factor? Sure. But instead of joining a Google v. Facebook API deathmatch, Google chose to create and gather support for a set of standards that benefit everyone. They have done a great job of catalyzing the effort and getting it going, but this is now bigger than just one company announcing some APIs.

The main reason this is true: market forces.

As I said in my previous post — no doubt there will be extensions, but the nature of this market is such that if you deviate too much developers won’t support your platform. Developers in this market (iLike, Flixster, RockYou, Slide) have little if any direct ties to the container providers (Ning, Orkut, LinkedIn, Facebook), so developers really have the power to maintain things sane, since they will certainly optimize to make as few changes as possible and maximize exposure of their apps. It’s been a while since a wholly new, truly competitive market where the users have a lot of “say” in the distribution (which generally happens across notifications and Activity streams) has emerged.

It’s one of those rare ‘rising tide lifts all boats’ situation. For developers, service providers, and, more importantly, users, who get more choice in terms of what site they use, without having to sacrifice on features.

And I think it’s great news. 🙂

opensocial: standards-based apps for all social networks

It’s all over the wire: the NY Times and Techcrunch first, quickly followed by Om and many others have posted about the announcement that we at Ning were going to make with Google and other providers on Thursday of a new set of APIs that will be supported across all services to enable social applications.

One of the things that is really significant about this is that it’s not vaporware. While the announcement doesn’t mean immediate availability, we do have, right now applications running on multiple test environments. What is also significant is that we’re not inventing a new markup language or things of the sort: it’s all standard XML, HTML, and Javascript. This is the key to bringing a high level of portability, which we will have right out of the gate.

For example, we have a great Flixster app that we will show, which runs on both Ning and Orkut, as well as others, unchanged. This is huge.

Let me say that again: as opposed to what some reports are suggesting (Mashable mentions some of these concerns for example), these apps can run unchanged or with fairly minor changes (if you’ve gone “off-road” from the base calls) in most if not all the supported containers. Will they all be able to run unchanged? Probably not, but it’s possible and certainly something that we should all strive for.

At Ning we are committed to supporting as much cross-service behavior as possible.

Given what the APIs are, and that it will be straightforward to add support for them, I expect we’ll see lots of sites getting behind this effort. Marc Canter just said that they will support OpenSocial as well and on a related point I agree with him: we need to make these APIs deeper.

Additionally, we should make an effort to make the APIs cleanly extensible and provide a mechanism to allow the extensions to become part of the standard. I mean, it’s obvious that there will be *some* extensions, and it’s also obvious that some of them will have wide applicability. And when they do, it’s going to be great if everyone that wants to can jump on board.

There’s still lots of details to work out, but this is very exciting. I’ll post more after the formal announcement on Thursday.

PS: for the record, regarding the New York Times headline of people “gang[ing] up” on Facebook, I can say that I’ve never heard anything even remotely approaching that sentiment. I would certainly welcome Facebook’s support for OpenSocial, and I imagine many others would, too. What Facebook has done is great — this is going to be even better!

the ning platform: yes, it is THAT cool :)

Albert Wegner from Union Square Ventures wants a new Platform.

He describes some of the characteristics of this new platform as follows:

A platform that is created from the ground up to enable modern web sites and applications. What would such a platform look like? It would be hosted and (nearly) infinitely scaleable. It would provide object storage that’s as simple as saying “here’s an object, store it” (you get back a handle, ideally, if you want a human readable, search engine optimized one). Later on, retrieval should be something like – “here’s a handle, give me back the object” (with full user level access control baked in). Stored stuff should be easily indexed so that one could say “give me back all the handles for objects that match this pattern” (and to which the user has access). The same should work for media: “Here’s a picture, store it for me with this metadata” and “Find all the pictures for me tagged x.”

Aside from storage there are other useful services the new platform should come with, since essentially every modern web site / application needs them, such user authentication, authorization and access control. Flexible processing of pretty URLs. Easy creation and maintenance of page templates. Ability to send emails and process bounces. Handling of RSS feeds (inbound and outbound). Support for mobile access and possibly even voice capabilities.

Code would run inside the platform (this is what Marc Andreessen calls a Level 3 platform) but it would not be cut off from the outside world. It would have full access to other services that live on the net via web services. So, for instance, there would be no need for the platform to have its own payment service.

Then he goes on to add:

Marc Andreessen lists companies who are working on it now, including his own Ning, Salesforce and Amazon. […] Despite the big guns already working on this, I believe there is still an opportunity for someone new to build the new platform.

(My emphasis)

Yep, he mentions Ning, but obliquely as “working on it” along with others. Ning is not just “working on it,” but we already have it running, and most of this has been running since the beginning — in fact, at the developer’s level, this is what we’re about.

Allow me to explain: let’s go over some of the requirements he mentions in more detail:

  • A platform that is created from the ground up to enable modern web sites and applications.
  • Hosted and (nearly) infinitely scalable.
  • Simple Object storage (not relational), supporting indexing, tagging, searching with user-level access control baked in.
  • Built in rich media support.
  • Flexible processing of pretty URLs (URL Rewriting).
  • User authentication and access control.
  • Messaging support.
  • Syndication support.
  • Everything exposed through webservice APIs.

Every single one of those requirements is currently satisfied by Ning. As I said before, this is not stuff we’ll release next month, or next year, or “at some point”. It’s stuff that’s running right now, and that has in many cases (such as the webservice APIs) been running for the full 2 years of Ning being live.

Thinking that Ning is “only” about providing easy-to-setup social networks is a common misconception with Ning, and we’re working to improve the documentation to make this obvious.

A lot of things on Ning are about the APIs we provide, and for a good reason. As I wrote before, you can think of the Ning platform as a giant API with a built in ability to execute arbitrary code against it, and both the code and the API access will scale transparently with your needs. Every Ning network runs on top of the API — there are no “special backend systems” or priviledged data paths, or anything of the sort. Therefore, the Ning platform is fundamentally different in this sense.

Here are some specifics of how the Ning APIs make this possible — “this” specifically the requirements and functionality that Albert was talking about in his post.

  • Ning provides APIs and default pages and UIs for user authentication and user account management.
  • Ning’s PHP APIs actually just wrap the Ning REST APIs. The REST APIs are front- and back-end symmetric, i.e., every single API is accessible from both the external world (as a webservice) and internally from the Ning execution environment itself. Internal requests are automatically validated for access (given the user’s current login/pwd) and external calls support HTTP Authentication.
  • The Ning Content Store supports, through the REST APIs, arbitrary, dynamic content shapes that don’t require a schema to be predefined (the schema is dynamically defined at runtime). For more on this see The Ning Content Store: A Primer.
  • The store also scales transparently and has implicit fault-tolerance.
  • The Ning backend supports image manipulation after upload, including resizing and rotation, and video transcoding from most current Codecs into Flash.
  • Rich media (including arbitrary attachments) can be stored as attributes within Content objects and then referenced normally, using the built-in search mechanisms, tagging support, etc., along with high-level aggregation functions that, for example, automatically return tag clouds for content you upload.
  • Content is available (given appropriate user credentials for private content) through built-in Atom APIs that can be consumed in any feed reader. Additionally, the social network application provides many built in wrappers for feeds in RSS format.
  • URL Rewriting is built in. (Note — we use this a lot, but our Forums and Blog still lack in this respect, so the permalinks are, let’s admit it, pretty ugly).
  • There are also APIs for searching, Messaging, role management, and large-scale group formation and management.

On top of these base services there’s the Social Network code itself, which you can obtain for your copy of the network (it’s free, after all) and then modify at your heart’s content. This code contains tons of higher-level functions, libraries and APIs that can be leveraged to build higher-level components very easily.

We will improve the documentation and examples in these areas dramatically over the next few weeks and months, but in the meantime, if you have special requests or questions, you can join the Developer Network and post them. Or just ping me. 🙂

one small REST call for man, one giant API for mankind

Here’s a question I’ve heard a couple of times recently: how committed is Ning to the platform idea?

It’s question that emerges from our need to focus right now, as a company, on building out the social network application on Ning and empowering Network Creators from the top-down, through simple but powerful tools, to customize and evolve their networks.

Given our limited resources, this creates sometimes the external impression that we’re not paying much attention to Ning as a platform, or to the evolution of our APIs, or the support of them, but nothing could be further from the truth.

Without the platform, there is no Social Network application. Allow me to explain.

When you create a network on Ning today, you get to add features, customize its appearance, change profile questions, privacy options, and more, all through a straightforward drag-and-drop user interface.

Hidden in this process is the fact that the network itself, and every feature in it, uses the APIs of the Ning platform to do the job.

“But wait,” I hear you say, “everyone and their pet has an API these days! How is Ning different?”

Here’s the difference: Every single Web API out there, except for Ning’s, is a parallel plug into the backend that runs the service, website, or application in question.

Every other web site out there (that I know of) has a set of separate systems that deal with API requests — it’s how API access to other sites can be slower, or more unpredictable, or be more restricted than access to the site itself (see the image to the right for the Layers in typical websites). Every site has its databases and various server systems that compose the service they provide. Then (in most cases after the service has been launched) an API is added as a way to expose some of the data or services provided by that website/product. I am not aware of any API out there (except for Ning’s, that is :)) that exposes all of the website’s services in API form — perhaps GData‘s comes closest. Most APIs allow you to read data, sometimes a lot of the available data, and a few let you perform several specific write operations–GData again being a good example of this.

So what is it with this exception I keep making for Ning? What’s special about our APIs?

The answer is there when we look at it the other way: it’s not so much that Ning’s APIs are special, but that the Ning Social Network is built entirely using them. Every application on Ning written by Ning is built using the same APIs available to anyone else on the platform (and even for external remote calls).

Anyone could have built the Social Network application on Ning, starting from scratch. There are no special, high-privilege data paths. There are no hidden authentication systems. There are no datastores that are available only to Ning.

Layers within the Ning Platform


The Ning platform is one giant API that runs on what we call the core, a collection of hundreds of servers and dozens of server types that power the platform, presenting a homogeneous view of data and services through a variety of HTTP-based REST APIs.

The Ning APIs are built using REST, but PHP applications running on Ning have access to them through a thin layer of PHP code that simplifies their use from within PHP. However, it is possible to use the Ning REST APIs directly from PHP, It’s just a little more cumbersome. In the future, when we add language wrappers, we will use the same APIs as the underlying mechanism to access the Ning services.

So going back to the question: how committed is Ning to the platform? The answer is simple: We are 100% committed to it — if we were to remove features, or change them, or disable them, every network on Ning would be affected.

The reliability, performance, longevity, and availability of the Ning APIs is exactly the same for everyone modifying the Social Network code, or creating new apps from scratch.

The platform is our DNA. Simple, but not easy. 🙂

2 years of ning!

2 years ago tonight we launched Ning. Back then, every time we told someone “It’s an online Platform for Social Applications” we’d generally get back puzzled stares. Today, it has become more mainstream (although not completely), and a little over a week ago we passed 100,000 networks on the platform. But there’s still more to do. And a lot more coolness down the road. 🙂

new ning release!

A new release of the Ning Social Network is out. This time it’s all about Network Badges and new Widgets. Weee!

%d bloggers like this: