Archive for February, 2011

Marc Hedlund joins the Fluidinfo board

Wednesday, February 9th, 2011

We’re really happy to announce that Marc Hedlund has joined the Fluidinfo board!

I’ve gotten to know Marc slowly over the last 10 years. We first met very briefly when he was CEO of the Popular Power, a San Francisco start-up. Nelson Minar (Marc’s co-founder) and Derek Smith, two of my close friends who are very close to Marc, were both working there. Nelson and Derek, as well as several others including Fluidinfo investor and advisor Tim O’Reilly have sky-high opinions of Marc. Hearing regular off-the-charts superlatives about Marc over the years always kept me interested to someday know him better.

Marc was present at my first ever (abysmal!) solo VC pitch for Fluidinfo, to the ill-fated Bryce Roberts and Mark Jacobson of OATV in early 2007. During the presentation, Marc interrupted to ask if he could take a photo of my slide titled “Revenue”. I think he wanted it as an example of how not to pitch a VC. I’ve never forgotten. He snapped the pic, resumed his seat, and told me to carry on 🙂

Marc has a ton of experience. He founded and led Lucas Online, the internet subsidiary of Lucasfilm, was director of engineering at Organic Online, and was also CTO at Webstorm. After Popular Power he was VP of Engineering at Sana Security, and then Entrepreneur in Residence at OATV, gaining intimate knowledge of the world of venture capital and interacting with hundreds of start-up companies. Marc then co-founded Wesabe where he was Chief Product Officer before becoming CEO. These days he’s Chief Product Office at Daylife in New York.

As you can probably imagine, we’re honored and excited to have Marc involved at Fluidinfo.

Wanted: a UI/UX virtuoso who wants to help change the world

Monday, February 7th, 2011

Image: brandon shigeta

Fluidinfo is an always-writable information layer designed to hold metadata of any type about anything. It has an information model simple enough for everyone to understand – as simple as using Post-it notes. We’ve reached the point in development where we want people as well as applications to be able to create and interact directly with information in Fluidinfo.

Our core and driving passions are based on thinking about how humans work with information: how we find, consume, create, remember, organize, and share. We’re looking for a UI/UX wizard who also thinks and cares deeply about these things, and who has experience and exquisite taste in building elegant and super low-friction interfaces to information. Someone who can tell us what Tufte got wrong, and why.

Most of our computational experiences take place in read-only environments, or ones in which we can only add information in ways that have been anticipated and approved. This read-only world makes working with information using a computer very unlike the way we work with information in the natural world. A read-only world inhibits ad hoc, creative, unanticipated uses of information. It inhibits personalization and customization and therefore effective filtering. It is wrong because it puts information ontology ahead of evolution, inhibiting the natural emergence of information communication conventions like @addressing and hashtags.

With Fluidinfo we’re trying to imagine and build a computational world in which we always have write permission. In which people are free to add information to anything – to personalize and customize, to filter and search on their information and combinations of information. A computational world in which we can collectively make information more valuable by storing it in context.

There’s a huge and challenging UX/UI component to this. We believe humans are actually very good at working with raw information. It’s applications that are confusing. Part of our challenge is to create an interface to anything (i.e., in a web of things sense) and to do so in as transparent a manner as possible.

We’ve been thinking about these ideas for years and have built Fluidinfo as a platform to support this kind of simple and always-writable information storage. Now we want to put a face on it and we’re looking for someone truly great to join us.

About Fluidinfo Inc.

Fluidinfo is an angel and VC backed start-up based in New York, which is where we want you. (Our development team is currently distributed.) We have a world-class set of investors, including: Betaworks, IA Ventures, RRE Ventures, Lerer Ventures, Chris Dixon and the Founder Collective, Esther Dyson, Tim O’Reilly, Joshua Schacter, Michael Parekh, and Andrew Rasiej.

We’ve been quietly working on architecture since our seed funding in 2010, but are now starting to show the world the kinds of things we want to enable. Just for a small taste, read about the writable API we recently built for BoingBoing in a single evening, or how to use Fluidinfo to put metadata onto tweets. To get a flavor of what Fluidinfo is aiming at, see Truly Social Data, Information. Naturally, Fluidinfo as a universal metadata engine, and Kaleidoscope: 10 takes on Fluidinfo.

We also have some exciting news coming up on Feb 14 at the O’Reilly Tools of Change conference in NY, so keep an eye out for that too.

About you

We’re not going to tell you in detail what skills you need, because you’ll hopefully know that better than we do.

As a guideline though, in terms of technology for UI, we’re mainly interested in things built using ubiquitous web tools and standards like HTML5 and Javascript. We’re less keen on Flash, and cannot stomach heavyweight proprietary UI platforms. Anything that requires a clunky download is a non-starter. We do everything with Linux and will be very happy if you know your way around that world too. Experience with mobile or desktop UI/UX will also be valuable.

The three most important things we’re looking for are, in order of importance: 1) brilliance in UX/UI thought and execution; 2) proficiency in building dynamic web content with Javascript / modern HTML etc; 3) graphic design skill or experience working with graphic design teams to convert working prototypes into beautiful products. 1 and 2 are much more important than 3.

Above all though, you need to be able to show us interactive interfaces you’ve built or designed, be passionate about UI/UX, and be able to talk convincingly and in depth about what makes things work and not work.

Hiring process

To apply, send email to jobs at fluidinfo dotcom and include:

  • An outline of why you’d like to join Fluidinfo
  • A CV
  • Pointers to your previous work
  • Names and contact details of at least two references

Hiring will involve initial telephone/skype interviews, to be followed by in-person interview(s).

Dropping FluidDB as a product name, in favor of Fluidinfo

Friday, February 4th, 2011

As of today, we’re dropping FluidDB as a product name and will just use Fluidinfo (which is of course also the name of our company). We’ve obviously put a lot of energy into the FluidDB name so it feels bad to know that some of that will be squandered, and that we might create short-term confusion with the change. But the downsides of a bad name are both real and important, and it’s time to fix the mistake. I’ve run the name change idea past dozens of people over the last two months, with almost universal approval—some of it very enthusiastic. So from now on it’s Fluidinfo, and only Fluidinfo.

Here are the main reasons for the change:

  • Having two names instead of just one was a source of confusion to many people.
  • The term “database” has too much inappropriate baggage. The mindset around databases is that they are used to carefully hoard and protect one’s own information. Fluidinfo is about combining information, about putting it in the same place, about openly writable objects with a different model of control. It’s a completely different mindset. Programmers, especially, have expectations about databases being something they download and incorporate into their application to hold just their data.
  • We were never particularly interested in the NoSQL debate (see also this O’Reilly GMT interview). Being occasionally classed as Yet Another NoSQL Database was inaccurate and led people towards apples vs oranges comparisons and confusion. For example: How does Fluidinfo compare to Hadoop? (note the two problems here – until now Fluidinfo has only been a company name, and FluidDB does not compare to Hadoop in terms of storage).

We very reluctantly began using “db” with the only purpose being to try to help VCs understand what we were building. That was before ideas of “cloud computing” and data as a service became well understood. It was helpful back then, but is not helpful now. Fittingly, after living with the baggage for a long time, the straw that broke the camel’s back was a VC who told me he almost didn’t take our meeting because he assumed from the name that we were just another of those NoSQL databases. When he said: One way or another I’m going to get you to drop that name, I knew we’d gone full circle—an inappropriate name had finally been recognized as being detrimental by the kind of person the name was supposed to be helping.

The name change can already be seen on our funky website (desperately in need of a facelift) and in the Fluidinfo documentation. We’ve also switched our Twitter account to @fluidinfo and are now using the #fluidinfo channel on IRC.

We’ll soon be moving some web pages around behind the scenes to improve their URLs, but will make sure the old links still work. If you’re interested in technical details of the API, please feel free to ask questions below, to join us in the Fluidinfo users mailing list, or to drop by the #fluidinfo channel on

And….. stay tuned, we have some exciting Fluidinfo news right around the corner.