The whole photo album is available here, but here are some of my favorites:

This was my first StartupWeekend, but I’ve been following it since the first Boulder weekend and have really wanted to attend one. It was even more fun than I expected. I met some great people, learned a ton, and got a great thrill out of collaborative work. And that was really the best part of startup weekend for me: the people. I’ve said it before, but it’s really becoming a mantra for me: you build a company around good people, not good ideas.

The other intriguing part of StartupWeekend is the social experiment of self-organizing groups. Conflict happens. Put hard-working people in a small room together and throw in some profit incentive and conflict is bound to happen even more. Peter, Erica and I discussed group organization as the weekend wound down and I realized my inclination is to shepherd, to guide with a firmer hand. But I don’t think that’s a good solution. I think the “teach a man to fish” cliche applies here. If you lead too actively, you destroy the chance for spontaneity and lucky surprises. Plus, maybe the that conflict arises is also useful.

It’s possible that StartupWeekend (and other self-organizing conferences) reveals who you really are. If you have a tendency to sit back and let others do all the work, that’s probably what you’ll do at StartupWeekend. If you’re a control freak that can stand to share the glory or let others have input on an idea, you’ll probably alienate everyone in your group. If your only interested in profit, you’re probably severely misguided because I won’t even begin to discuss the odds of building a profitable business in a weekend: that’s missing the point. But if you favor collaborative work, are eager to encourage others, enjoy sharing of yourself and your ideas, and like getting things done, you’ll have ample opportunity at a StartupWeekend.

If that’s really true, if StartupWeekend reveals how you relate to others, then maybe the purpose of StartupWeekend is not to start a company, but to learn about yourself. And that’s something all of us could learn more about.

1. Create an algorithm to generate a tree according to a set of predefined parameters.
2. Build an editor that allows the parameters to be modified by some intuitive controls (sliders, drop-down menus, etc.)
3. Turn over the editor to users and track which trees the user saves or exports (this counts as a “vote” for the “goodness” of the tree).
4. Generate new random trees, favoring random trees with a lower distance to “voted” trees in the high-dimensional space.

There are several promising aspects of the technology that are worth mentioning in particular:

• User-defined design space exploration- As Vladlen mentions in the video, the vast majority of trees in the design space are simply not tree-like. As users played with the program and created their own trees, the trees that are saved are used as votes for the trees goodness. This is reported to be similar to the way that voting will happen using the editors in Spore, Will Wright’s new game that is built around several procedural editors. It’s a powerful idea for determining the pockets of goodness in a sea of procedural randomness.
• Map analogy for space exploration- After the space has been parameterized and the areas of the design space containing “good” trees has been determined, the user is allowed to explore the space on a two-dimensional map-like landscape similar to Google Maps. This analogy is familiar to users. Furthermore, as the user zooms in on an area, they are exploring more closely a particular region of the multi-dimensional design space and the trees in that space resemble each other more and more closely the further the user zooms in. Others should take note of this method of design space navigation.

Kudos to the Stanford group on the tool and the polish behind it. I look forward to seeing what objects are explored next. 

1. Startups are about people. Finding good cofounders really matters. Finding good employees at the start really matters. “If you have a good team, you are halfway there.”
2. Determination matters. Max was absolutely determined to get his technology to work. He pulled all-nighters. He coded until it got done. 
3. Naivete can be a strength. Max wasn’t aware of the technical challenges they were going to come up against in dealing with fraud, but was confident they would solve the problems as they came up. “People like Citibank and other large financial institutions that also competed with us that understood the fraud thing very well–they knew from years of practice that this was going to become a huge problem–didn’t really approach it with the same happy abandon that we did. … We thought, ‘we don’t know how to do this; let’s just invent it.’” Sometimes not knowing how hard a problem is can be a blessing. You may approach the solution from a different angle or try something that others had been unwilling to try because it appeared to daunting.
4. Entrepreneurs just want to start something. Perhaps my favorite quote was about his drive to start a company: “I think the hallmark of a really good entrepreneur is … you realize one day that you can’t really work for anyone else. You have to start your own thing. It almost doesn’t matter what that thing is.” I know exactly the feeling. There is something empowering about working at the startup level. It’s like programming in assembly–you have access to the bare metal, no abstractions or obstructions.

Max has continued to show his drive for starting something as he has moved on to work on Slide and Yelp.

The man who has no refuge in himself, who lives, so to speak, in his front rooms, in the outer whirlwind of things and opinions, is not properly a personality at all. He floats with the current, who does not guide himself according to higher principles, who has no ideal, no convictions–such a man is a mere article of furniture–a thing moved, instead of a living and moving being–an echo, not a voice. The man who has no inner life is the slave of his surroundings, as the barometer is the obedient servant of the air at rest, and the weathercock the humble servant of the air in motion. -Henri-Frédéric Amiel

The major restriction that seems to be getting attention is:

Only one iPhone application can run at a time, and third-party applications never run in the background. This means that when users switch to another application, answer the phone, or check their email, the application they were using quits. (p. 16)

There are only two types of interactions that this limits that I can think of:

• The iPhone needs to do some processing in the background, for example, triangulating coordinates to see where you are and storing that information for later.
• The iPhone needs to check the internet in the background for periodically updating information, possibly notifying the user. Examples include an IM client notifying the iPhone owner of an incoming message.

While annoying, I think some common applications can still be implemented but what will have to happen is the paradigm will have to change slightly. In the case of an IM client, rather than having a constant signal represent “being online”, someone will have to create an iPhone-Online mode where messages sent to the user are queued up on a server somewhere until the iPhone user opens the application and pulls down the most recent messages. This could be done as a layer that sits between the iPhone and AIM or the IM clients themselves could implement this functionality.

In the case of a lot of applications, the actual processing can take place on the server or only while the application is open. When the user opens the application, processing can take place on the iPhone and the state can be saved in a local sqlite database or on a remote server. When the application is reopened, any additional processing done server-side can be downloaded.

For example, for a time logging application, the user can open the iPhone application and “punch the timecard” so to speak. The application can store the punch time on the phone and the user can then turn the phone off. Whenever the user is connected to the internet and the application is opened, the time log can be synced with a server.

This limitation isn’t a deal-breaker, but it will force developers to rethink the concept of “always on” that we’ve gotten used to with normal applications and web applications alike. The solution will end up being something similar to Google Gears.

We put together a JustNeem page on Facebook tonight for the company where we intend to post events, pictures, videos, and comments on our progress as a company. This is something of an experiment to let people see what goes on behind the scenes at JustNeem as well as what life is like in Mauritania. I’ll be writing about how this experiment goes over time.