If you’re building a new product, your biggest risk isn’t that you won’t be able to reach a mainstream audience, but that you’ll fail to attract even 50 users that love your product.

When embarking on a new venture, your goal isn’t to implement any specific idea in the best way possible, but to iterate as fast as you can, till someone is passionate about whatever product you’ll eventually converge on. Don’t worry about being scalable or cross-platform. So what if IE6 users can’t use your app - you’ve yet to find anyone that wants to use your useless app anyway. Anything that reduces your speed of iteration is poison to your startup at this point.

Yes, we ridicule companies that fail to scale when they start becoming successful, but keep in mind - they’ve become successful and that makes them extraordinary in so many ways. Maybe they didn’t become successful despite being scrappy, but because they were scrappy. Seriously, once you have users that want to use your product but can’t because your tech sucks, you’ve basically won. After all, what you’ve been doing is product discovery, not software development. The tech really is the easy part, since it only becomes important once you have something that people actually want to use.

This article was inspired by a heated discussion on irc.freenode.net #startups about whether not supporting IE and even Firefox is a viable strategy for an early-stage startup. My thoughts are above. I’d love to hear yours. Discuss over at Hacker News.

I just found some of my old blog posts on archive.org. I thought they’d suck, but whoa, they’re not half bad. Really, the only thing better than listening to yourself speaking, is reading your own words. Brace yourself, World, i’m blogging again!

PS: BTW @tumblr, why does layouting a blogpost have to be such a pain clusterfuck in 2009 2010?

Florian Hufsky (“Flo”, “oneup”, “Hufsky”) war mehr als ein geliebter
Freund, mehr als ein Pixelkünstler, Hacker und Spieledesigner. Flo war
jemand der konstant mit einer Leichtigkeit Ideen, Konzepte, Code und
Projekte produzierte, die Ihn nicht bloss nach einem Medium für seine
Ideen suchen liess, sondern zum Medium seiner Ideen machte. Jemand der
mit 23 bereits eine Partei, mehrere Spiele, Startups, und eine
Künstlertruppe gestartet hatte, und jemand der Freunde und Familie
hatte die Ihn wirklich liebten. Nicht jemand der etwas sein wollte,
sondern jemand der etwas war, und dessen Beiträge und Inspiration noch
lange in Design, Produkten und Diskurs weit über dieses kleine
Alpenland hinaus widerhallen werden. Und dennoch war er nicht
glücklich, fand nicht die Perspektive und Liebe die Ihm gebührte, und
sah scheinbar keinen Ausweg. Mir blutet das Herz daran zu denken, dass
er etwas übersehen haben könnte - ich wünschte er hätte mehr gereist,
hätte mehr gesehen - vielleicht wäre da etwas für Ihn gewesen. Doch
unendliche parallele Welten, und wir enden in einer in der ein Freund,
ein Vorbild und Inspiration mit so viel Potential, uns bewusst
verlässt. Ich kann nicht abschliessen damit, ich spüre nur Wut,
Tränen, Verzweiflung. Sein Licht brannte hell, und Ich bin dankbar für
die Zeit die er mit uns teilte. Danke Flo!

English

Florian Hufsky (“Flo”, “oneup”, “Hufsky”) was more than a beloved
friend, more than a pixel artist, hacker and game designer. Flo was
someone who produced ideas, concepts, code and projects with such
ease, that he didn’t just look for a medium for his ideas, but he
himself became a medium for his ideas. Someone who at 23 years of age
had already started a political party, multiple games, startups, and
a digital art troupe, and someone who had friends and family that
truly loved him. Not someone who wanted to become someone, but someone
who was someone, and whose contributions and inspiration will continue
to be felt for a long time in designs, products and discourse, far
beyond the small alpine country that he was born in. But despite all
this, he wasn’t happy, he didn’t find the perspective and love that he
deserved, and it seems he saw no way for himself to achieve happiness.
My heart is bleeding when i think that he might have missed something
- i wish he had travelled more, had seen more - maybe there’d have
been something for him out there. But despite the infinite parallel
worlds that we live in, we end up in one in which a friend, a
role-model and inspiration with so much potential, has left us
intentionally. I can’t comprehend, I can’t move on, I only feel anger,
tears and despair. His light burned bright, and I’m thankful for the
time he shared with us. Thank you, Flo!

me coding at the google wave campout (by david newman)

Most observers are portraying Google Wave as the future of email or instant messaging, and celebrating or criticizing it as such. In the blog posts I’ve read, Wave’s merits are analyzed solely based on the current developer UI preview. Calling it a preview is giving it a lot of credit - let’s maybe call it a debugger or proof-of-concept instead. Or in other words, people are discussing Wave like it is the newest social networking website, and not an infrastructure protocol under heavy development.

So let’s ignore the high-level “next-gen E-mail” sales pitch for a moment and take a look at the state of Wave today. At its heart is a technology called Operational Transformation (OT). It defines a set of operations, transformations, and the documents they can be applied to.

For Google Wave in particular, the components involved are:

1. Documents that can be rendered to HTML.
2. Operations and series of operations that can be applied to documents: For instance, insert a character ‘c’ at position 5, then delete the character at position 9 (Note: this is an example, not how wave’s operations really work).
3. Transformations of Operations: These are rules to change operations, so that if operations are received in different order on multiple clients, the document still eventually converges to the same consistent state.
4. Robots that can monitor operations and create new operations based
   on the operations previously applied to a document.
5. An early draft of a federation protocol that allows documents to be
   hosted on arbitrary servers instead of a central location, for example
   at Google.

That’s pretty much all there is to it. It essentially defines the data structures of a collaborative document editor, and we don’t really know yet where many of the components attached to them will lead: The federation API is still a moving target, there’s no client/server protocol, and robots speak yet a different moving-target protocol. Add a web UI (which right now doesn’t even properly speak OT, and is built on an unspecified and GWT-specific protocol) and what you have is a collaborative web document editor with big ambitions. That’s exactly where Wave is right now, and the competition has been here before (maybe without the big vision, but who’s to say?).

Now where can we go from here? HTML is a document display system repurposed as an application platform. Wave seems aimed at the same route. So how could that application platform look?

Let me explain using an analogy.

Traditional programs can either directly access input and output devices like keyboards and graphics cards, or they can use the X-Windows protocol, which is more abstract, but has certain advantages. With the X protocol, programs request graphics operations instead of instructing the hardware directly. This level of abstraction enables multiple programs to work on the same screen, cooperate with copy&paste or enhance each other like window managers do.

Programs can even use the X-Protocol over a network, which
means that a program and its server with the screen can run on different
machines. I say in theory, because graphics operations are ill-suited
for high-latency, low-bandwidth environments such as the Internet, and
X-Windows is a particularly chatty protocol. More efficient solutions
like RFB/VNC and NX have been developed, but in general, the pixel transfer paradigm has proven inferior to the high-level web application paradigm that has parts of the UI logic running on the clients in JavaScript.

Now I’m arguing that this new webapp paradigm is still like talking to the graphics hardware directly. Developing custom JavaScript code for changing documents requires re-inventing the collaboration and interoperability wheels over and over again. Wave could be the heart of protocols and standards upon which we can develop the next generation of applications without re-implementing everything over and over again for each new app. Apps would be robots, possibly partially running within the browser, and all I/O would be operations on documents.

This means that every Wave application would be collaborative “for free”, and
you could combine multiple apps to interoperate on the same documents, like a latter day OpenDoc. Eventually, documents could be more than just static data, and using the same protocol and algorithms to build, let’s say, a collaborative Photoshop in Wave is entirely possible, just like classic web applications have transcended the original scope of HTML.

To give you a little background: I am a software engineer working on distributed systems, and particularly on OT algorithms.  I am posting this from the GTUG Campout at the Google Campus in Mountain View where I have just built a few Wave-based apps with my co-conspirator Jacob Rus. Among them is a collaborative scientific computing environment (think Mathematica or Matlab - but based on the awesome Python Scipy environment - screenshot here), and a Wave Robot IDE, which allows you to write wave robots collaboratively from within Wave. Both projects will be opensourced soon. You should follow me here on twitter, if you want to get updates.

Thanks to Christiane Ruetten, Jacob Rus and someone knowledgeable who can’t be named for reading drafts of this.

Discussion and comments on news.yc!

While at the GTUG Campout in Mountain View, Jacob Rus and me turned Google Wave into a collaborative Scientific Computing Environment using scipy.

In many ways the European model of starting companies is a waterfall model - that is, progress is seen as flowing steadily downwards - there’s no going back and changing your goals when you’ve learned new stuff about your business.

I’m not saying that every company is started like that, but that that’s how the existing big companies have come to be. It’s still a part of culture, even though small startups are beginning to change that perception. In Europe the culture seems to be that big companies are willed into existence by the government as a public-private partnership when a need has been identified by the bureaucrats and political leaders. The goals are clear, and design happens after the money is on the table and an initial committee of experts has been recruited. All that’s left to do is build the product and company. That’s the way the numerous telecoms, postal services, the austrian mineral oil authority or Volkswagen and most other big european corporations have come to be.

It comes natural to governments to try and apply the same model to the new companies that are needed to compete in today’s information economy.

Good examples that this is in fact happening are the Theseus project (€250 Million from French and German governments to build a semantic search engine), and the Quaero project (€90 Million from the French Government to build a multimedia search engine). Bureaucrats learned from Google that search is a big deal, and now want their own search engine. Wheels started turning and thus they recruited a team to build them one.

Note that there’s no Entrepreneur in the picture: People are placed in these newly-formed projects mainly through nepotism and reputation. Landing a good position in such a company can be the entry-ticket to becoming part of other committees, and thus a start into a good and stable career. Individuals aren’t incentivized at all to care if the project succeeds (would a government-owned european search engine really change the global economy?) - just having been there is enough to get on more committees and projects on the future. 

Compare this to the startup approach, where a bunch of people get together with a rough idea of what markets they want to tackle and then just get started. HP’s business plan famously contained the sentence “The question of what to manufacture was postponed until later in the discussion”. It’s not that the product doesn’t matter - in fact the incentives of the founders are much more strongly aligned (running out of money, most likely their own) with having to find something that works, than in any other known scenario.

It’s just that the long-term value of the organizations isn’t really in its assets anymore, but in the capability of the organization to try new stuff and adapt. It’s not so much about choosing the right thing to do, but about being able to throw stuff at the wall, and see if something sticks, before you run out of stuff to throw.

Hacker Culture is all about trying stuff. Iterate fast, fail fast, and try again. Hacker Culture is Entrepreneur Culture in its essence. European culture is still stuck in the delusion of actually being able to control things. Just cherry-pick the right decisions and you’ll succeed, so goes the thinking. The entrepreneurship culture in the States with its ideal of giving everyone a shot at trying, and not punishing failure seems much closer to the hacker culture that’s needed to build meaningful companies for the times to come. Before Europe will get its own tech startups of meaningful size, a huge change of culture is needed. I see hackerspaces as a way to bootstrap a culture that is more open to try new things - or rather live it right now.