Jean Sini: structured communications

We’re moving. It’s a good thing we love the food at the restaurants around South Park, though, because we’re likely to remain daily visitors there: we’re only traveling a couple of blocks. But there’s more: unlike the food, a lot else is going to change in the move.

Here’s the short, Twitter-friendly version: we’ve just been acquired by Buzzlogic. We’ve been talking to the team there for over six months: they rock. So I’m totally excited, elated, ecstatic, thrilled, stoked, and psyched about the deal. Did I mention I was excited?

A longer version follows, and you can also get more details about the news from the usual suspects.

I started Activeweave with Marc back in 2005. We built two products, BlogRovR and Stickis. Ever since, we’ve been focusing all our energy on building technology that would delight our users and help them as they go about their busy lives online. We’ve been working on doing one thing well: making it easy for you to stay informed in the face of ever growing quantities of content (some signal, some noise) fighting for your attention.

BlogRovR in particular has resonated with close to 200,000 of you, faithfully fetching posts relevant to the page you are visiting, from the bloggers you choose, and bringing them right into the browser as you go, for just-in-time context. BlogRovR connects readers and bloggers anywhere on the web where they have something of interest to say to each other. For a reader, it means seeing what your favorite bloggers have to say anywhere you surf, and for a blogger it gets your message to your readers beyond your blog or their feed reader, everywhere on the web where you have something to say.

We do this with an on-the-fly, personalized, contextual search. We’re nerds. But we don’t mind that others have thought this a mouthful and called us Techmeme on steroids, the Muhammad Ali of feed readers, or web 3.0 today instead.

We met the folks at Buzzlogic a while back and hit it off: they’ve been preoccupied with the blogosphere as well, working on technology to map conversations in a fine-grained fashion, tracking influence, and allowing their customers to better target their research and advertising. We saw the right synergies, we saw complementary business models, and we saw a great team in action.

We also saw a novel business opportunity. Buzzlogic is using an analysis of the blogosphere similar to ours to help advertisers identify its most influential regions, on which to message potential customers. Buzzlogic calls this conversation tracking. Both their current technologies and the directions in which they’re taking them align well with what we’ve done and the kinds of products we’ve been building. The more we talked about possible collaborations, the more areas of overlap emerged. It soon became clear that our technology could help inform Buzzlogic’s influence tracking, and that we would also be able to contribute personally to their future.

So, we’re moving onto even wider challenges from the ones we’ve been facing: Jean will become the Chief Technology Officer at Buzzlogic, and Marc will become Senior Vice President of Product.

The last two and a half years have been a wild ride. I remember reading on someone’s blog (where else?) only weeks before launching the company, that being an entrepreneur requires a hefty dose of irrationality: one has to find a way to brush off the countless near-catastrophic failures, the endless doubts, the crazy daily grind, and the reality of doing everything on half a shoestring, in order to thrive instead on the rare breakthrough, or the occasional unsolicited friendly message from a happy user. Indeed, we experienced all of this first hand. But as Winston Churchill put it: success is the ability to go from one failure to another with no loss of enthusiasm.

There have been innumerable of you who’ve helped us along the way, and we can only really name a few by name. Many have helped with ideas, enthusiasm, exposure, and guidance. We’re particularly grateful to our investors, who’ve supported us financially and who’ve continued to believe in us throughout. Special shout-outs to Eric Di Benedetto, our lead investor and board member, and Esther Dyson, a key investor and advisor.

BlogRovR isn’t going away. If anything, it’ll benefit from the improvements we keep making to the underlying technology, from the talent at Buzzlogic, and from their mighty hardware too.

Just as importantly, we remain committed to respecting our users’ privacy: we’ve been clear all along about what value we deliver as you browse, and we’ve been equally clear about how we use the data we come in contact with in the process of delivering that value: we only use it anonymously and in the aggregate. We don’t store individual click-streams, and instead derive aggregate attention metrics based how you interact with RovR.

Cross-posted to the Activeweave blog.

Brad Fitzpatrick, of Livejournal and memcache fame, and now a Google employee, just announced the release of the social graph API. It leverages the public, explicit relationships declared in XFN or FOAF by various sites, and harvested as part of Google’s crawl, to expose someone’s graph in a form suitable for building applications. In these days of growing Facebook fatigue, this could help bring the vision of an ambient social network, where your graph (i.e. your posse) travels with you everywhere you go instead of being trapped in a particular site, one step closer to reality. Caveat: Google has shown its willingness to end support for popular APIs before, so there’s clearly risk involved in building anything dependent on this.

Social Graph API - Google Code

Blogged with Flock

Tags: socialgraph, api, google code

[…] Zuckerberg’s most important backer, Peter Thiel, does not work on Sand Hill Road. From his offices in San Francisco’s Presidio, he’s set about changing the rules of how startups get funding and how founders make their fortunes. Through his Founders Fund, he has begun issuing “Series FF” shares to the entrepreneurs he backs, giving them the right to sell shares alongside their companies to new investors. Thiel, who felt unjustly treated as the cofounder of PayPal, wants to let his protégés build companies without worrying about how to make rent. Old lions like angel investor Ron Conway will probably view this development with outrage.

Scoop: Mark Zuckerberg cashes out?

Or, as Mashable puts it: nice pocket change for Zuckerberg.

Except it didn’t happen: Valleywag retracted the story.

So much drama for a Saturday.

Tags: startups

Facebook has accepted Microsoft’s investment of $240 million. The deal gives Microsoft a minority stake in the company at about 2%, which also gives Facebook a current valuation of $15 billion.

Facebook Worth $15 Billion, Accepts $240 Million from Microsoft– bub.blicio.us

Tags: web2.0 facebook

Damn. I did it again: it’s not even noon yet and, just like the car talk brothers always say, I just wasted another perfectly good hour. Except, this time, I spent it tweaking my buddy list on Twitter and answering a deluge of invitations from folks on various social networks.

As an entrepreneur deep in the trenches of the evolving web (take that, web x.0 versioning zealots!) I should love that stuff: I started our company in that space precisely because I want to make the web a more social, participatory place. And at first glance, it seems we’re finally getting there, with the Internets chattier than ever. There are more and more fantastic options available to publish all sorts of content, from concise status updates to events to full-length blog posts to podcasts to video. And tools to share the goods with friends are mushrooming as well. What’s not to love, right?

Well, something about the pattern emerging right now bugs me. As a whole, I fear the social web ecosystem is currently amplifying the pain rather than actually helping users communicate and interact better. I read an interview with Aaron Swartz a few weeks back, where he mentioned that early Reddit users wrote about spending too much time on the addictive site. Like Aaron, I am not sure this is a good thing. I am hooked on Twitter, for instance, but I hate loving it.

Why? Because as someone not merely out there to kill time, but rather looking for valuable information nuggets, I don’t feel empowered; quite to the contrary, I feel played: since when does it count as progress that I have to manually sift through everybody’s mundane whereabouts just so I don’t miss the rare piece of signal in the noise? Sure, I want to know where the party’s at, but there has to be a better way to find out than following 1,234 users just to catch the few valuable announcements between countless quips about cappuccino runs and BART delay.

Twitter (or Jaiku, for that matter) isn’t a worse offender than others, mind you: I am frantically trying to keep up with numerous meeting trackers and calendars, from Outlook to Google to Yahoo to 30boxes to upcoming, not to mention old school evite. And should I update my profile and connections on Facebook today and on LinkedIn tomorrow, or the other way around? If I also have to watch the life-casting of my 50 closest friends, I might just as well give up on work right now.

My point: massive production overload, lack of any potent filtering. It may be fine for a while, or for die-hard exhibitionists and voyeurs, but I feel like we’re letting users down severely when it comes to having the stuff that matters to them bubble up to the top of their attention.

To answer Mike’s diatribe about the Valley getting rotten because of too much cash, too many parties, I’d say that in terms of innovation, we’re barely getting started: in my view, the point’s not only giving users yet another megaphone, but facilitating interaction, collaboration, online or even (let’s dream a little) in first life. While the promise of a web more participatory is what fires me up, I think we need to seriously ramp up the consumption side of things. And search in its current state is not the answer; it simply isn’t keeping up right now. Yes, I keep tabs on who’s writing about my company with blog search, but what is the Technorati tag for personalized “cool stuff, cool events, or cool people”? What’s really hot, in my view, is a chance to build and deliver that kind of filtering value for users, beyond gimmicks and raw entertainment plays just adding to the noise. What do you think?

I can’t believe a year has passed since Mike Arrington last covered Stickis. We haven’t exactly been idling, but neither have Mike and his growing team. Nick Gonzalez has since joined the Techcrunch clan, and does a great job explaining what we’ve been working on since early this year: an overlay metaphor for the web, that lets you elect a set of trusted sources, from friends to blogs to services (that last bit is still at the experimental level), and bring this community along with you as you browse. Rafe Needleman, over at webware, goes in-depth as well. Point taken, Rafe, we still have room to grow in the “make it simple” department. We’re excited to be opening up stickis to a broader user base with the launch of the beta, and start collecting as much feedback as possible. Some of that’s already coming in: the MDX Lab seems to like our approach, including the whole “antisocial tag” bit, and Red Dixon groks the value this brings to publishers, who show up on their subscribers’ browsers whenever contextually relevant. Meanwhile, Liz at Gigaom, while she also gets the antisocial tags, isn’t as convinced (just yet): Liz, feel free to ping me any time and I’ll give you a tour, now that we have a Mac friendly Firefox version running.

Timboy paints a pessimistic outlook for the semantic web, coining the term semantic web disease. I am not convinced. While I see the potential myths of the Semantic Web promise, and the perspective Timboy is highlighting, I am optimistic: judging among other things by the heavily publicized experimenting on-going around the self-healing properties of collaborative systems like Wikipedia, I think there is hope. While not directly relevant to the Semantic Web itself, Wikipedia shows that trust can be built in large scale voluntary systems. In the case of structured information, if there is a lot to be gained (in terms of processing automation) from attaching the correct meaning and meta-information to data, there is a good chance for shared meaning to converge instead of diverge.

I just started hosting activeweave, a project I have been working on in my spare time. For now, it is a simple web-logging platform offering free weblogs to authors, both in French and English (years at Oracle have taught me to build internationalization into the very early stages of any design effort). It has the basic capabilities you should expect from such an engine, letting you upload and post photos, and allowing you to customize the look and feel of your weblog entirely, thanks to a template-based approach on top of a Java Server Pages infrastructure and custom tags. Ultimately, my goal is to turn activeweave into a laboratory, with dynamic features introduced to measure how they enhance teamwork models, by mixing workflow events with authoring, editing and annotation tools, thus streamlining a lot of the processes at play when building and maintaining technical knowledge in a group.

As software engineers or architects, we work hard to build products and solutions that meet or even anticipate the needs of our target markets. As software engineers or architects, most of us also have, for better or worse, minds of the somewhat logical kind, of the kind that can scan through pages of cryptic C++ code and identify flaws in algorithms, hunt down optimistic but groundless assumptions, and extirpate performance bottlenecks and security risks. When we reach the limits of what those minds can handle directly, we don’t hesitate for a second; we know just what to do: we pull out the profiling and debugging tools it will take to track down and eliminate the more elusive issues.

But then, here’s a question for those minds, logical or not: why can’t we seem to make use of those same deductive skills when it comes to grasping a shared, solid, and essential understanding of those market needs, and of the technological challenges in meeting them? When it’s time to devise the all-important, the critical strategies we build our products and bet our careers on, why do we tolerate so much hand waiving, so many approximations, and put up with so blatantly missing logical steps?

Of course, complexity is an obvious suspect. The tasks of exhaustively analyzing customer demographics and problems, of tying these to market sizes and growth rates, and then of figuring out the best ways to address the most valuable needs using technologies available to us appears simply daunting.

Surprisingly enough though, complexity doesn’t seem to be discouraging us, or even slowing us down: thousands of product managers, marketing gurus and strategists (not to mention the ever-fascinating evangelists) are busy slicing and dicing and making sense of all this. Of those, the mediocre are ineffectual, the worst so myopic they will drive any project into the ground, and we view the best as mythical, visionary heroes, whose prophecies we accept to follow somewhat blindly, because even they cannot quite break their views down into a complete, logical, contained analysis.

Now, don’t get me wrong: I love good story telling. In fact, I firmly believe that eloquence and oratory skills are a key to success in our business world. However, do they have to substitute for sound thinking? If the complexities we face are such that our brains cannot process them entirely, isn’t it time we give ourselves the tools we really need?

As the saying goes, a picture is worth a thousand words. Yet every meeting you sit in (and the more strategic the crowd, the more acute the phenomenon is) quickly turns into an exercise in rhetoric with little attention to the white board or even to the seemingly boring notion of defining the terms we use as unequivocally as possible.

Similarly, while we are all aware of the power of diagrams to convey meaning efficiently, we spend a large proportion of our time writing and storing email messages away in fast-aging mailboxes. These messages (often in the form of streams of consciousness that fit so well the monologue model of weblogs) lack the structure and the concept definitions that would allow us to turn them into actual exchanges building shared knowledge.

I see a number of possible improvements we can make, leveraging several technologies still under-utilized today: of course, the wiki concepts (if not their typically raw look-and-feel) constitute one of the founding blocks of such a potential tool.

In addition, an advanced notification mechanism, traversing links or better yet reverse-links, is required to let a group know about changes in a particular area of the knowledge base and their possible effects on neighboring notions.

We need this reverse-link traversal paradigm in order to capture causality in the system and give it a way to evaluate the implications of change. This is where we can really start tapping into our CPUs to supplement our brains in order to keep track of logical connections.

In addition, as we start characterizing links (in order to designate various causal relationships between concepts), we need to be more systematic about these concepts themselves. Consequently, the semantic web technologies (in particular the taxonomy aspects) are a third critical element of such a knowledge building tool, as they let us capture meaning in a structured fashion intelligible not only to the human reader but to software.

Finally, adequate representation is essential, as it is the key to efficiently communicating concepts.

None of these technologies has been widely adopted yet, but I think spending energy building the tool that lets us bridge them and systematically communicate using this combination will be a better investment of our effort and time, and will tremendously speed our work when it comes to establishing and maintaining strategies.

Unsurprisingly, when trying to abstractly model behaviors, events and processes in a given domain or system, dissecting and studying actual, concrete scenarios plays a critical, dual role: experimentation with real-life material, that exhibits the exact behvior we are trying to model, not only proves a very helpful way to ground and strengthen the understanding we have of the phenomena we are describing (thus enabling us to model them), it is also a necessary step in validating such a model: real-life examples provide the required test-beds allowing us, iteratively, to refine, adjust, and ultimately design a model suitable for use beyond the examples actually studied. This methodology (draw an abstract model from concrete experiments, then validate the model with more real data-points) is very common (see Eliyahu Goldratt’s take on it in his Theory of Constraints).

This approach can obviously be applied to the domain I am covering here: building and maintaining structured knowledge. What are good models for such knowledge building systems? And what is a good, real-life scenario where such a system would be useful, so I can dissect and study it, build a suitable system, and eventually use it to generalize a model of such systems.

One such scenario is the challenge to produce useful functional specifications for software products I am working on. Usefulness is a concept we could philosophize about for a while, however in this context it simply means that the document (in its evolving revisions) is a reliable and exhaustive source for reviewers (who came up, directly or not, with requirements from customers) to determine whether what we’re planning on building is up to their expectations, while it also is a precise enough source of information for developers to unequivocally build the said piece of software. This simple definition carries a lot of constraints, as it pushes onto the specification the responsibility of ensuring that the product eventually meets the requirements, but that’s what a specification is about, after all.

First, such specifications clearly constitute a valid scenario of structured knowledge: they are meant to convey to readers a massive amount of structured information about a product that is being built, they need iterative refining and evolving, and due to the nature of the contributors and consumers of these documents, they need co-authoriing and workflow processing support (to run through cycles of iterations). By nature, their content,and the implicit decisions it reflects, need to be justified to both the readers charged with validating the underlying requirements, and the readers tasked with implementing a suitable software component matching the same: thus, functional specifications (and their maintenance) exhibit the characteristics of a typical structured knowledge system.

Second, functional specifications are, in my view, an interesting problem to tackle, because while no-one will typically argue that anything larger than a small development project should do away with them, instantiations of such documents that truly meet the usefulness criteria above are very rare. Building useful specifications, therefore, can’t be simple, and frequires solving a number of complexities that we’re bound to face with any structured knowledge base, so that solving these functional specifications issues will help solving the more generic issues of structured knowledge. On the need for evolving, useful functional specifications, read Joel Spolsky’s articles, Painless functional specifications.

I position the features of a support tool for such a task (building useful functional specifications) along two dimensions:

• Process Management This dimension groups all the features related to the process of co-authoring structured documents: workflow, notifications, inline editing and commenting, change management, fine-grained addressability and so on. These features are pretty much orthogonal to the type of structured documents the group is trying to author.
• Structure and Content Management This dimension is more specific to the domain or type of knowledge being accumulated. In the case of functional specifications, the structure of the document, once ready for review, must make it easy for readers to understand what product they are going to get if developers build according to the specification. This structure is very fine-grained, and I would say it needs to be adjusted to every type of software product being built. For instance, if we’re building packages where the user interface plays a big role (as opposed to, say, a faceless package that solves a particular type of math equations, or implements a given networking protocol), then the structure must place a lot of emphasis on the graphical interface, leave none of it to the reader’s or the developer’s imagination, otherwise the contract that the specification represents isn’t precise and fine-grained enough. For enterprise application software, for instance, 2 key elements of the specifications should be screen-shots of mock-ups and possibly performance indicators of response time to the end-user. Determining the right structure and format (possibly using templates) for the completed document is, thus, a fine-tuned exercise that will affect vastly the usefulness of the effort. The importance of structure and format relates back to the learning quality of a knowledge base: how well it allows readers to grasp the concepts it carries. I don’t believe there is a unique format, best suited to convey any message. Instead, just like professors will pick and adjust educational tools and methods to best explain concepts they are communicating their students, the nature of the knowledge to share should drive the format of the communication. Rich on pseudo-code snippets when algorithms are discussed, rich on video, screen-shots when graphical interface is key, etc.

The one feature set that relates to both the tool and process used to build and share knowledge, and that knowledge itself, is the group of features exposed to allow editing of the document in the most convenient fashion. Whereas auditing, approving, tracking comments are all tasks pretty much orthogonal to the content they are processing, the tool(s) used to edit this content are inextricably dependent upon the structure of what is being edited. Text is the common denominator, but if you want the tool to be aware of the structure (in my example, if you want the tool to know about features, sub-features, dependencies, assigned resources, priorities, etc.) and facilite authoring along the natural structure of the product being specified, then you cannot be generic, instead you have to use a rich, specific editing tool. Fine-grained addressability actually falls in this category, since allowing reviewers or co-authors to edit video clips, or images, assumes they have the ability to make precise references to portions of such elements.

Now, what does this mean for my current challenge, building useful specifications? I will start by enhancing the XML Schema describing specifications tailored to my current project. While this enables me to embed images, even audio and video clips, addressability remains an issue. Then I will need to tackle the problem of how to render the document: I am thinking of a very dynamic, multiple views XSLT style-sheet that gives multiple perspectives to different readers, or enable one reader to successively focus on different aspects of the software being described – one important aspect is to keep conveying the context, regardless of the view, to allow readers to know where they are in the document. This set of issues are very specific to the domain of software functional specifications, and even constrained to the type of software I am specifying – I will tackle these first, in order to make sure I can at least come up with the right underlying and presentation models. Tools for process management, as described above, are more generic and I will tackle them when the structure and content management features are clearly defined.