Author John Borthwick

firef.ly goes public beta

We are pushing firef.ly into a public beta today.   Exciting stuff for us here at betaworks.   Firef.ly is a light weight messaging layer that sits on top of a site — permitting a real time perspective on who is where on your site and basic chat.   It’s intentionally light weight — no sign in, no install for users — one line of java script for the web site publisher (available here: http://firef.ly/install).  You can use firefly on this page — just slide the slider to the left and have fun.

Couple of thoughts here — first this is another layer application, something i have posted about before, second this is for me a return to days when you could just chat on any page — without the encumbrances of today, captcha’s, sign in etc.   Its a layer of the now web that we are experimenting with.    Yes yes i know it might get some spam — but web site owners have the ability to ban spammers and our hope is that the lightweight, spontaneous nature of firef.ly may open up some new conversations.    As it did a while back when we first trialed it on a Scripting post.    Last point — try the twitter feature — it sends out a message to your followers that you are on a particular page, its pretty powerful.   Have fun.

Summize acquired by Twitter

As announced this am, Twitter is acquiring 100% of Summize. Deals between two private companies are easy to consider and hard to close. In this case we had both companies on a tear and the teams on both sides who were interested in a partnership — the hope here is that what makes sense today only makes more sense down the road. Search on twitter will evolve into more than search — this is starting to happen today (more below), but bringing these teams together will only accelerate the pace of that evolution. The deal started with a conversation with Fred Wilson about how conversational search can evolve into navigation, about how important navigation becomes for UGC as you go mainstream — it concluded with the deal that was announced this morning. Betaworks is now a twitter shareholder, and excited to be one.

Finding a pain point
The history of most startup’s is made up of iterations, learning and restarts — Summize was no exception. The Summize team worked hard for a little over a year developing sentiment based algorithms aimed at crawling the review and blogosphere. Late last year they formally launched a web product that let you search reviews for books, movies and music. It worked well — offering summaries of all the reviews for a particular book, structured programmatically so they could be organized and swiftly digested by users or publishers. Yet it was complicated — not in theory or in its presentation — but in practice it was a complicated problem that most end users didnt know they needed. As an old friend would put it Summize v1. didn’t address a discernible need or pain point.

I remember early this year we took the Summize team over to meet with an executive at News Corp. After the WSJ/Dow Jones acquisition, News Corp. was thinking about data centric media and how conversational media — the blogosphere — can be mapped and structured in a scalable manner. Jeremy was fascinated by the technology but pushed us hard as to whether we knew whether people were really looking for programmatic structured access to sentiment. By March it was clear we couldn’t get the sentiment focussed company funded by VC’s — many people were interested but no one was ready to take the risk. I think this is part of the chasm between east and west coast companies — out west, interesting technology can and is often funded purely on the merits of the technology — out east, not so. At betaworks we decided to work with the Summize team repoint the technology — and launch twitter search. Why Twitter? Three reasons: there was a gap in the market for a scaled search / navigation experience of twitter, summize technology was very capable of providing and scaling a great search experience across the twitter’s live river of conversations and finally Twitter, the base data set, was growing like a weed.

Growth
It’s astounding how fast the Summize service took off. The growth is charted in this post. The premise was that there is a real time data distributed across services online that is hard to digest and that search is a well know metaphor to aggregate up these conversations into something meaningful for people. Twitter was the logical starting point — traffic was exploding and Twitter was quickly becoming a real time, one to many communications platform. Search is so often viewed as a destination experience — get this result and move on. Summize search is different — because its conversational and real time you keep searches running and open in tabs, you repeat them time and time again, to watch the conversation evolve and change — watch that refresh bar on any of the topics linked to above. The approach worked. Traffic exploded, not only on the UI but also on the API. Distributed, live search — very, very different to how search has been done to date on the web.

Now web
There is something new going on here. Somewhere in the past few months the way that I experience the Internet and specifically live information changed — there is a “now web” emerging out of an ecosystem of loosely coupled products. There has always been an immediate, instant component to the web and web communications — it goes back to mailing lists, IM, email & blog commenting. But its taking on a whole new form — the density of the conversations and the speed at which they emerge and evolve is different. I first sensed the shift with the trending topic list on front page of Summize. This is a feature that the team created right out of the sentiment based technology of Summize v1. The first night we launched v2. I recall seeing the word IMAP was trending — my first thought this has to be a mistake, but when I ran the search it turned out that Gmail was having IMAP issues. Then a few weeks later during a telephone call one participant on the call heard an explosion outside his home. He jumped off the call to see what was happening, Jay came back 5 mins later, shook up but with no idea what the noise was. This post shows the Summize stream of responses to a simple question — there had been a minor earthquake in VA. A few weeks later the earthquake in China was also emerged out of the twitter stream before it hit MSM.

We experienced this again last week — in full force — when we launched the bit.ly product. A deceptively simple URL shortener that we developed with Dave Winer. Six days after its launch bit.ly is on a tear. The launch last week started with a fantastic write up by Marshall Kirkpatrick — it moved from there into twitter and summize and within mins we were getting live feedback on the product, how to tune and test it, complaints about the lack of privacy policy and ton of great ideas. I am learning as I go — but its a whole new world out there and thanks to Summize we can converse with in a far more direct and organized manner. This should be evident again today — run a search for this or this and watch it evolve.

In summary
Summize is a great example of what we aspire to do at betaworks. Working with a great team of technologists who created a wonderful product, one that on the surface is deceptively simple — where the smarts are all under the hood. One that we helped launch and scale. Many thanks to the Summize team. Jay, Abdur, Greg, Eric and team worked very very hard to make this happen — they peered into startup abyss and decided they werent going there — you guys are smart and brave. Thank you to the advisors who worked w/ Summize the make this happen — Gerry Campbell and Josh Auerbach. And thanks to the Twitter team. I have great hopes for the joint team.

Also see Summize post by Jay

Summize growth

Summize organic traffic growth, week over week.   Its astounding to see the Summize business grow from 0 to 14M queries a week in over the space of two months (note I updated the chart with the past week) —  traffic over the past 2 weeks has made the insanity of WWDC hard to see on the chart.

A testament to what a great product and UI can achieve in no time at all.   This past week with the launch of bit.ly I spent much of my time on Twitter, Summize, Friend Feed and a handful of other services.  Google is playing nxt to no part in the now-web that is emerging out of this ecosystem.   Rafer also pointed me to this chart on compete.    More on search and navigation to come, for now some pictures — Summize traffic and a wonderful fireworks display from this evening in Shelter Island.

bit.ly a simple, professional URL shortener

We launched bit.ly yesterday and got an intense amount of buzz and attention.  We thought this was an important piece of the puzzle but didn’t fully appreciate the vacuum that we were running into.   A crazy day — Summize offers a great interface into the groundswell of activity — Nate, Jay and the team iterating and updating the service throughout the day (you can see the updates here). 

On the switchAbit/bitly/twitabit blog we did the official launch post.  Save you the jump here is the summary of what we offer and why its different

1. History — we remember the last 15 shortened URLs you’ve created. They’re displayed on the home page next time you go back. Cookie-based, sign in will come but the first rule of the game was keep it simple.

2. Click/Referrer tracking — Every time someone clicks on a short URL we add 1 to the count of clicks for that page and for the referring page.

3. There’s a simple API for creating short URLs from your web apps.

4. We automatically create three thumbnail images for each page you link through bit.ly, small, medium and large size. You can use these in presenting choices to your users.

5. We automatically mirror each page, never know when you might need a backup. :-)

6. Most important for professional applications, you can access all the data about each page through a simple XML or JSON interface. Example.

7. All the standard features you expect from serious url-shorteners.    

And it’s just the beginning, we’re tracking lots more data so that as more URLs are shortened by bit.ly we’ll be able to turn on more features.   Marshall talks about some of what we are going to do on the data side in the RWW article below. 

More to come on how this fits with switchabit, twitabit, findings — the cluster of services we are building.    For now some commentary:

ReadWriteWeb

Bit.ly Is a Big Deal URL Shortener

Scripting News

Alley Insider

Summize

NilsR


 

Summize and Hahlo

More data on Summize search and how it changes the way people interact with Twitter. See this tweet:

I’ll save you the jump. The chart below shows the effect on pageviews of Summize integration into Hahlo. Search changes the way people interact with an application — see the engagement jump.

Zemanta Pixie

Summize and Twitter

On monday Summize ran a test partnership with Twitter to cover the WWDC, the results were fairly extraordinary (a colleague mailed me … “holy fuck”).   The raw data is displayed below. Traffic peaked at 190 queries per second, spikes went way over that number. For context — this is close to the search load that AOL manages today (at its peak AOL was doing several x that number).

People came, they searched … but they also seem to have left the browsers on, watching the WWDC conversations flow by. This is interesting and unusual — search as a browse/monitor experience is different to the way search has been thought of to date. We have also seen this with the trending topics on Summize. Conversational search is a big idea – the Summize team are starting to figure it out.

Picture 2.png

Zemanta Pixie

web 2.0 & making money

Article in today's financial times about Web 2.0 companies making, and not, making money.   I think the article is right and we are likely heading for some consolidation — but the article misses the most interesting points about why and how that consolidation will take place.  Its a fairly typical turn of the tide article — replete with a bonus quotation from someone who just raised a lot of money.     Moving on from the drama of MSM — start with why there will be consolidation of some form.  

The web 1.0 companies who survived and prospered did so mostly on the back of Google —  its distribution and its monetization platform.    The fact that many web 2.0 companies have yet to turn a profit is an indication that (a) Google's  platform is still not optimized for this generation of web services and that (b) Facebook, the company everyone expected to provide an alternative, has thus far failed to  provide a platform to build a business.    A year ago this week I drafted an essay on why I believed the Facebook platform needed to offer Web 2.0 applications more than just distribution — its a year later and the data is starting to be tabulated.    Facebook has left a wide gaping opportunity for others to drive into –and companies driving in to fill this gap need to scale social graphs and in order to do that they are opening up — Facebook's misstep, accomplished two moves on the chess board!    They had a chance to build another walled garden but now they are in a struggle to the bottom (or top) of who can become more open — very good for the web as a whole and, specifically, very good for web 2.0 companies.      

Moving to the how.    This shift will pry open opportunity and monetization platforms across the web – and its likely we will have diversity in this system, it will likely be much more sustainable than web 1.0.    While this change is taking place its important to grow audience, manage costs and experiment with monetization approaches that follow the grain of your service.   And lastly, the consolidation the FT talks about — may not be the typical consoldation we see as busssiness go through changes — many of the web 2.0 companies have managed overhead/costs very aggresively, there might be opportunities to loosely couple parts instead of the organizational pain that mergers spawn.    More to come on this later when I have some time to write.    

Compacting connections

Interesting article by the founder of Meetro about what he learned from his startup experience.   Intrigued by the discussion about launch and member growth — he talks about how it first took off in Chicago and then it started spreading into small communities around Chicago.   A lesson I leant at Fotolog was the value of compacting social networks — its counter intuitive but it makes sense when you think about it.     Communities need to be compact or tightly connected at the outset in order to reach critical mass.    Duncan Watts has done a lot of great research on this — Adam Seifer taught me about it in practice.    Raw growth is not the right metric to focus on when you start a social network — you need to measure and track the density of those connections — tight, compacted social networks grow faster than thin broadly distributed one's.

Firefly

We launched the conversational overlay Firefly this week.  We had planned to roll out Firefly at tech meetup but Dave Winer was in our office on tuesday am and we gave him a preview.    He wrote a post and within 5 mins this is what his blog entry looked like this:

FF

In this picture you can see his blog about firefly with firefly active on the page.  Everyone present on the page is represented by a mouse icon and some of those people are chatting within firefly.    I wrote a piece about overlays and layers of the web a few weeks ago and firefly is a great example of this layering idea.   Its also a return to the early days of the internet —  when would crawl into some corner of the net and just start talking with someone — community and people were far more present than they are today.    Firefly offers up a layer of interaction where conversations can take place while people are still remain in context on the page — no download, no extension, no registration, just people on a page.    I had a crazed week but wanted to put up this screen shot before the weekend hits.

Couple of related links:

Summize search on firefly, a good way to find whats going on

Blog post on Firefly, and another

Future of news

I saw the future of news unfold today.   We were on a conference call with Jay who was in Falls Church VA – he heard an explosion – Dave posted the question on twitter and in the space of two hours the tweet-o-sphere figured out it was a small earthquake.      There is still nothing on the subject on Google or Google news, let alone MSM.

You can see the tweet stream below via a search on Summize.  We  talk about this stuff ad-infinitum but its amazing to see it unfold before one’s eyes.   The first tweet is from 1.35pm right after the quake.   The last one on the screen shot was approx. 3.10pm — it links to the confirmation from the USG:

(USGS has confirmed a magnitude 1.8 “micro” earthquake occurred near Annandale, VA at 1:30pm.  There have been no reports of damage or injuries.)

note the screen shot below is a compilation of tweets, re-run the search on falls church at Summize.com

summize / earthquake

Dimensionalizing the web

What is a web page today? If you look at the average web page, it’s a compilation of a diverse set of data sources drawn into a construct that we think of as a concrete whole. It probably started with CGI — and the first commercial application was likely the ad banner — but today that simple web page is made up of a whole mix of things ranging from dynamic content, ad’s,  widgets, sidebar tools, gadgets — the frame that we think of as a web page is now constructed from data streams in from all these sources and more.   This componentization of the page was the first step in what is becoming a different architecture for information delivery. What we have today are the equivalent of early life forms – necessary building blocks that evolution will use as more sophisticated lateral services develop. The organization of data streams and how they are constructed relates to our understanding of the dimensions of the web.

Question?   What would the web look like if you picked it up and looked at the bottom? I imagine, what you would see would be a set of databases – with streams of data flowing between them, into these things we call web pages and between these things we call web sites. These metaphors we have applied to the web — pages and sites — are analog’s that helped us grasp and structure the web, yet like any proxy they also impose limits on our perspective. RDF/RSS started me thinking about a lot of these ideas but in the eight or so years since those standards were developed our understanding and approach to web sites as vertical businesses has barely evolved. The spacial assumption we imposed on the web — that a site is a discrete experience that a publisher can control — maps with both a human need to impose hard edges on a dynamic, complex system but also with how we have understood media for the past 100 years or so. I think those edges are been broken down and are offering a different view of the web, and therefore of media companies, one that is less structured around the hard edges of a web page or site, less vertical, less about data silos and more about dynamic, fluid use of data and connections between data points. Some examples.

Take a look at this picture of this post I found on tumblr last week. This person — Erin — is using tumblr to announce a meetup. In this case email and reblogging are the tools she is using to confirm attendants. Shouldn’t this person use meetup for this — clearly its their preference not to, but why?

tumb log

I would propose two theories: context and easy of use. First context — context is important, Erin has followers (an audience) on tumblr, she has an environment that is customized with a user experience she could control (nice background) — and so she wants her meetup to appear in that context. Ease of use — for a myriad of reasons it seems it was easier for her to roll her own meetup than use meetup.com or to quote Pip Coburn the perceived benefits outweigh the perceived pain of trying to learn something new. So here is an example of someone molding a use case (creating a meetup) into another web experience to fulfill a need.

Example #2. What about Twitter. What is the web site Twitter.com?   The first answer — the one I would tell a stranger in conversation — is that its a destination to access and use the microblogging service provided by Twitter, “want to try one to many micropublishing? go to twitter.com”.   Sounds simple enough. Yet that conclusion isn’t supported by the data. I don’t have the exact number but I think its safe to say that more than half of the interactions with Twitter occur off Twitter.com — and the number is in all likelihood a lot higher than that. So is Twitter a protocol?, maybe.   Maybe Ted Stevens actually understood the web better than we thought — thinking about Twitter as a pipe makes more sense than as a  destination.   But its not a pipe in way that old media understood pipes — its different, im not sure i understand exactly what that difference is going to yeild but what is clear today is that each interaction that takes place on the network add’s value or context to further interactions.    As data chunks move around Twitter the get organized and collated into conversations and meme’s.  Similar to the Meetup example — each node on the twitter network is contextualized in form that makes sense for that particular interaction. But unlike Meetup, Twitter is powering all these interactions. The data becomes more valuable as it moves from interface to interface — not less.     There is something very powerful that is happening with the simplicity and openess of this network.   A network is the best metaphor I can think of for Twitter.

Another example.  Iminlikewithyou — the flash casual gaming site, started off as a destination (disclosure note, a betaworks company).    All of a sudden users started grabbing the code and syndicating their game on to their web sites.    But this isnt just the game — its not a widget model — its the entire underlying game net that is getting syndicated.     IILWY is closer to our understanding of old media but its contains some of the bizarre distributed breadth and possibilities that Twitter holds.

So where does all of this lead us?  I believe we need new metaphors to understand and place dimensions around what a web experience is. I don’t have an answer but I do have a few thoughts on how we can begin to frame and understand the shape of what is to come.

i) Think Centers vs wholes, think about networks vs. destinations

Pic by CALast week I was re-reading Christopher Alexander the Nature of Order . In the first book he has a section about wholes vs. centers. He makes the argument that composing visual structures as whole’s — thinking of buildings, things, windows — anything as a whole — fails to recognize the context in which the object lives. He builds the argument up starting with a dot on a piece of paper — he then analyzes how the dot divides and structures our spacial understanding of the piece of paper.  From this point he starts to frame up a way of looking at the world that is based on thinking about centers, zones of spatial activity vs. wholes.   An example he cites:

“On one occasion, I was discussing the concept of centers, as it applied to some bedroom curtains, with my wife Pamela.     She made the comment that the use of the word “centers” as I had explained it to her, was already changing her view of everything around her, even as we were talking: “When I look at the curtain in the room, and think of the curtain, the curtain rod, the window, the sky, the light on the ceiling, as centers, then I become so much more cognizant of the relatedness of all things — it is as though my awareness increases”

I think Alexander’s point and work here is profoundly applicable to the web. If you start thinking about centers — clusters of information — vs. destinations and vertical sites, for me at least, it gives me a frame of reference a metaphor that is far more expansive and networked than the one in which we operate today.   At Fotolog I learned that centers can form and cluster with remarkable speed within a community — now this is starting to happen with information moving laterally between domains.

ii) Think what can move laterally and encourage it to move

People, those things we often call users, want to take data and move it laterally across the web.   They want it to exist in context’s that make sense for a particular interaction. Whether its data portability standards, micro-content standards, people want to cross post and move data from one service to another. There is much that needs to be done here.   A year ago when F8 was launched it seemed that Facebook was driving headlong into this domain.   Yet a year later it now seems like Facebook might become known as the last portal, the last walled garden experience — data comes in but not out.   Openness of interface, api’s — letting data come in an go out of a domain is central to this thesis.    The Facebook newsfeed could be a web wide service — instead the way its articulated today is about retaining eye balls and attention — a movie we have seen before.  Last week we started talking publicly about SwitchAbit — SwitchAbit is a service that is designed to help drive this lateral movement of data across the web, while retaining context, its a small contribution we are hoping to make to this larger puzzle.

iii) Think about how to atomize context so that it can travel with the data

Dirty DataAtomizing content is one piece of the puzzle, the other is doing the same for context so it can travel with the data as it moves around the web from center to center.    Outside.in — Steven Johnson’s creation — trawls through blog posts and attaches geo context to individual posts. I sometimes refer to Outside.in as a washing machine — dirty data comes in one end — Outside.in scrubs the data set and ships out geo-pressed results the other end.   The geo scrubbed post is now more useful for end users, publishers and advertisers.   A bit of structure goes a long way when the data can then move into other structures.   The breadth of what geo scrubbing can do is staggering — think about pivoting or organizing any piece of information around a map — the spatial dimension that is most familiar to our species.  A bit of context goes a long way.   (disclosure note, Outside.in / an investment of betaworks)

iv) Think Layers

There is a layering dimension that is worth consideration — there are services starting to emerge that offer functionality that is framed around exposing some separation between different layers of the web.   Photoshop is the software that first introduced me to the layer metaphor,  i still cant use photoshop, but I think I get the layer idea.   Google earth has applied a layering concept to mapping.   Similarly services like PMOG are experimenting with layers.   Back at betaworks Billy Chasen started working with layers about eight months ago.   He developed a simple navigational tool called Fichey that lets you navigate web pages independent of their domain – using a common navigational tool.    Want to flip thru the top digg stories? — fichey makes it fairly easy and fast.   This was just a beginning.    Billy has developed a service called firefly — it’s in testing now and over the coming weeks we will begin to preview it — but its all about creating a layer of interactivity that is contextualized with the web site you are on but its exists independent of that web site.

v) Accept uncertainty, keep it rough on the edges

What did Rummy say about the known unknown’s?    As we experiment and design these new forms of interactions its vital that we remain open to roughness and incompleteness on the edges of the web.   The more we try to place these services into the convenient, existing models, that we have used to structure our thinking thus far the more we will limit our ability to look ahead and think about these things differently.

This is just a beginning.   I hope these five areas have helped define and frame how to think about alternative data dimensions on the web.  Time to wrap this post up — enough for now.

Profile of betaworks

The deal put out a profile of betaworks.

Switching bits

Betaworks is starting to roll out SwitchAbit, our first homegrown product. SwitchAbit is a content router. A switchboard to connect one service to another. It will let people shuttle a flickr to twitter, or to tumblr, facebook or pownce or pretty much wherever people want. SwitchAbit doesn’t aspire to be another UI to aggregate data — in fact its the reverse — it assumes that people want to contextualize information streams within existing services and existing communities. I’m tired of companies seeking to jam users into a new user experience that is mostly designed to drive a business model rather than drive new, relevant or meaningful interactions. As a consequence SwitchAbit is designed to be a platform — Twittergram will be the first service that will be powered by the platform.

When we started working on SwitchAbit one of the foundational services that inspired us was Twittergram, a service that Dave Winer created almost a year ago. Few individuals have been more innovative in finding ways to move data — live & static data — laterally across the web. This lateral movement of data is exactly what SwitchAbit is about. Once we had an alpha version of SwitchAbit working I sent it to a handful of people, one was Dave. After a rapid set of email exchanges — we came to an agreement and Dave is joining SwitchAbit as an advisor. The last deal we worked on was back in Userland days, between AOL and Userland — after months we never managed to finalize a relationship — this time around we managed to get this done end to end in about an hour. Good stuff.

It’s less than six months since we setup the development team at betaworks and this is the first of three products that will roll out in the coming months. As I started to outline last week betaworks is a company that through focus and structure is designed to drive linkages and accelerate innovation across what we call our network. The intent is to create a set of loosely coupled components — some wholly owned, some partially owned — and drive innovation, context and value across the network — thru the exchange of data. What people today call monetization, but monetization as it applies to a network, not two isolated nodes. Over time this network will look like a company — I guess a media company is the best analog we have today — but a little different in focus, structure and purpose. And we aren’t going to start talking about new media, again. For now we are very excited about getting SwitchAbit rolling.

beta working

The past few months have been fast and hectic. The focus has been getting betaworks to scale. We call betaworks a platform for seed business creation — let me spell out a little more about what that means to us.

We are creating a network of companies — some of which we are building and some of which we are investors in — that are threaded together by a set of common themes and capabilities. A set of loosely coupled bits that over time we will seek to connect in ways that are meaningful. Some background follows on our perspective and intent.

I started betaworks in 2006 seeking to develop a new methodology, and platform, for seeding businesses. We gathered a small team and for a year we tested a series of different approaches to seed business creation. We learnt a lot, we had successes and failures, we intentionally kept it small — permitting us to learn fast, fail fast and make small mistakes. In hindsight the most important thing we learnt was a design principle. When we started out we thought we could design or architect elements of betaworks. What I learnt was that given that we dont know all of the elements we are going to thread together we needed to start by working, by building, and then in the practice of work let the components between the companies emerge rather than imposing a top down view of what the connections should be.

Mid 2007 we flipped our approach — and went bottoms up. We stayed small, under the radar, focussed on our theme, seeking not to be distracted by opportunism. We started identifying standards and methodologies to scale our work and stopped trying to over think the design. By the fall of 2007 we had assembled our learning and formally started to build out the platform. Six months later we have four things that we have built and we have fourteen seed investments.

Central to the design of betaworks is the assumption that companies building services with a common theme can and should profit from inclusion in a platform or network of loosely coupled bits and driving context and meaning across these sites is valuable. Portals are gone but a new metaphor has yet to emerge to replace the portal concept. The portal was grounded in the same set of assumptions as media has operated with for many years — as it recedes something new is emerging. Something that is more distributed — something that is not based on the assumption that erecting a walled garden around services is the way to build a sustainable long term relationship with users or a long term business. Something that actually encourages the movement of data across edge services, vs. building silos — as data moves and is exchanged it actually gains in value becoming more interesting to users not less. There is a hairball we are decoding, bit by bit, its right in front of us our job is to figure it out and scale it.

Someone said to me last week that we are a reverse incubator. Incubators share the peripheral services things that I believe entrepreneurs can and should get from the market (legal, hr, accounting, office space) — betaworks is designed to share core capabilities – software / IP, knowledge, data, standards, analytics, leadership, tools etc… Someone a year ago called it a funcubator — maybe a reversobator, or outcubator? — a little less George Clintoneque. enough.

Herman Buhl / a discussion with Joe Simpson

20041012xchogolisa1.jpg

Discussion of the life of Herman Buhl. An inspired life — talks about his dash up Nanga Parbat where he basically dumped the team and team leader and bolted to the peak. Took a while to find the image of where Buhl disappeeared off the edge Chogolisa’s broad (bride) peak. Amazed that no one has put this on to wikipedia yet.