Joi Ito's Web

Joi Ito's conversation with the living web.

We just started our Creative Commons fall fund raising campaign. I first want to thank everyone who has supported and continue to support Creative Commons. Thanks especially to those who have been sending money even just the last few days.

In this difficult economy, support from individuals has become exceedingly essential in our ambitious goal of establishing CC as a global standard and a household name. As a small nonprofit, we feel the pressure of limited resources and a strained economy. Our staff's workload is at capacity, so now I turn to you to help us bring CC to places we could never reach on our own. I hope you can join us in the challenge today to make an investment in Creative Commons - an investment of your time, your resources, and your content:

Our community has been behind our success from the start. We have hundreds of volunteers around the world (myself included) - legal experts, educators, artists - who have worked to port, translate, and propagate CC licenses in 52 jurisdictions and counting. When you support CC, you give meaning to the work of those dedicated volunteers, and the hundreds of thousands of people who have benefited from the sharing CC facilitates. When you license your content under CC licenses and spread the word about CC to friends and family, you become part of this growing network. Together, we will continue to lay the groundwork for an open and accessible Internet.

This year, we have set a goal to raise $500,000 USD from our community during our annual fundraising campaign. Your support, however big or small, will help us sustain our core operations and keep our legal tools free for everyone to use. It will enable us to continue to level the digital playing field and harness the power of the Internet to be a force for good.

We have already begun to see that force take shape. There now exist over a quarter of a billion CC licensed works and CC licenses have become integral components of organizations and industries worldwide, from Wikipedia to the United States government, from scientific journals to major universities. There is currently a huge class of shared cultural works that would not otherwise exist if not for CC. These works belong to you, to me, to all of us. I'm asking you to ensure a bright future for this developing and crucial community-driven culture.

Whatever value you find in the rich and vibrant culture of collaboration, innovation, creation, and participation that CC strives to facilitate, I urge you to visit to learn how you can help and give a gift today.

Also, if you have a blog and would be willing to put a button to on it to spread the word, that would be awesome.

From Upside/downside graphs
From Upside/downside graphs

Over the years, Reid Hoffman and I have talked a lot about venture investing and the things that make people successful in startups. Reid likes to doodle a little graph on paper napkins about downside vs. upside focus and I thought I'd expand that a bit and share.

Normal sales oriented companies and organizations have sales that grows month on month if the organization is doing well. While there is a tremendous amount of energy spent on increasing sales, typically sales are capped by some reasonable growth rate over time.

On the other hand, the downside of a company is nearly unlimited. Projects can cost nearly an infinite amount of money if mismanaged and there are a myriad of risks that can cost an operating company tons of money.

The larger and more established the company, the more the organization, as a whole seems to be focused on mitigating risk and minimizing costs as a way to increase earnings and protect itself.

Venture investing, on the other hand, is typically a fund or an individual with relatively limited downside. The most that you're going to lose is the money you've invested and your time.

The upside in venture investing, however, is hugely leveraged. If you're in a good deal, you can make hundreds and thousands times your money with very little incremental cost. The key is to make sure you're in the right deals and that those companies that will potentially knock the ball out of the park get all of the help and support that they need to maximize their chance of success.

In fact, most successful investors spend the majority of their time working on their successful portfolio companies and very little time on the companies that are doing poorly.

In many cases, the companies that are doing poorly need the most help and the intuition is to focus on protecting our investments. Many investors spend all of their time helping their poorly performing companies.

I think that the training from traditional businesses causes people to focus on minimizing the downside instead of single-mindedly focusing on the upside. However, in a venture investment, the MOST you will lose is the money you have invested. Getting 1 million of the 5 million that you invested back from a liquidation is not nearly as important as making sure you're in the next big hit and that the investments that have potential achieve their potential and find their acquirers and partners.

This also influences the way people negotiate contracts. A few percentage points or deal points here and there can damage, slow down or destroy relationships and businesses. Trying to get every last percentage point out of a transaction with a startup is fighting over something that's worth zero if the company isn't successful. It's much more likely to increase your chance of making money if you're helpful and supportive than if you've pushed the entrepreneur against the wall and taken every last percentage point out of the deal that you can from them.

It's stupid to be a sucker and it's not prudent to be sloppy, but squeezing entrepreneurs unnecessarily for that extra nickel isn't worth it when the probability of upside is what you're trying to increase and having more rights in a failure is really not going to make you rich.

I think that all good investors understand this focus on upside vs. downside and I struggle with partners, co-investors and entrepreneurs who seem to live in a downside minimization model. Downside minimization may save you money here and there, but over the long run, will never really provide the kind of returns that an upside oriented model will.

When I visited Chicago last, John Bracken and Brian Fitzpatrick aka Fitz from Google organized a very interesting meeting with people from The MacArthur Foundation, Google and various communities including some folks involved in government.

During the meeting, I talked a lot about my thoughts on innovation in the context of newer software development practices and frameworks like agile development and Ruby on Rails. As Reid Hoffman often says, if you're not embarrassed by your the first release of your product, you've released too late." The release early, release often ethos of linux combined with the amount of actual "real work" you can do in one week with Ruby on Rails and other languages and frameworks totally changes the game for early stage consumer Internet investing.

Generally speaking, it's probably cheaper and faster and more effective to make a prototype than to make presentation deck. It's also probably easier to test something on real users than to do lots of marketing and guessing. My recommendation to just about anyone with an idea is to just build the thing, iterate until you have some user traction, then pitch angel investors based on that traction. This is very much in line with the old IETF motto of "rough consensus, running code."

In agile development, you concentrate on doing short iterations with input from your users constantly feeding back into the next iterations.

The "opposite" of agile development is a long process of deciding what to do, anticipating the problems, writing an RFP, work with a contractor until the project is completed, debug it, and then maintain the thing.

The problem is, in the real world, things change and by the time you're done, you're often pretty far off the mark and usually the first version isn't right anyway - so you end up making something 2 years late and a hundred features off target. With agile development, you test, evolve and stay in tune with your users and let them guide you. You can also test and refactor more easily because each "story" or feature is smaller, tested and easy to isolate and remove/change. (Or should be.)

It was very interesting to me that the government folks perked up when we got into this discussion. I remembered a comment by someone at an conference (sorry, I can't remember who said this). The idea was that in big software and in government policy, it was easier to add features (lobby for things to be added into a law) than to remove features. Everyone has their favorite feature that needs to be added. There was very little incentive to remove features and complexity once it was in the law or the code. You end up with things like Windows, some modern cell phones and many of our government policies, turning into bloatware that's huge, too compliated for normal people to understand which doesn't really even do well what it was originally intended to do. I think that keeping units small, proper test suites (accountability at the object level), and agile development can help mitigate some of the causes of bloatware that loses touch with why it exists in the first place and ends up sucking almost all management energy into process.

Also, the idea of floating government policy and iterating rather than taking ALL of the inputs before starting some humongous project also probably makes sense if you have the right kind of structure and discipline. I think there are a lot of things that agile developers have figured out that make sense to look at when thinking about policy and other work.

1 - Extreme programming. Work in pairs on the same screen so that you're checking each other and you're learning each other's productivity and other tricks. Swap partners every iteration. This is a very good knowledge sharing technique.

2 - Test suites. Assume everything will fail. Test what happens when what you have built fails and how it affects the other objects around it. Make sure you will always know when something fails and why. Build system to be robust against human, network, financial, computer failure of the object and build backup systems. Test suites also help you figure out what breaks when you make changes to the system and helps you later when you want to change, remove or refactor stuff.

3 - Small. Keep the teams small, break big problems into small problems. Break the small problems into "stories" or short tasks that a very small group of people can do.

4 - No proposals, specs, RFP's. Use a tracking system like Pivotal Tracker for tracking the tasks, but don't do huge project sheets or try to decide everything before you get started. It's more important for each of the small groups to share their local context and that each small part works correctly and doesn't screw up the stuff around it.

It may seem counter-intuitive, but I think that having a lot of small groups focused on being robust and agile and relatively independent makes it easier for the higher level decisions to be made and retain focus on the mission. Micromanaging is huge and inefficient. Each small group provides inputs to the system and feedback from the "users". Unbundled and small groups makes the whole system much more flexible and "agile" and changes can be made quickly without breaking things and allows focus on context instead of structure.

A lot of my thinking in this area has come from watching Jay Dvivedi and his team at Shinsei Bank and also working a a little with the Pivotal Labs folks. Having written this rambling blog post, I'd still like to say that I'm still rather new to the whole world of agile development, but I think there are a large number of practices that are being developed that can be applied to many other fields including but not limited to government policy development.

Just arrived in Japan after a visit to Chicago, Dubai and Singpore - three major hub cities. It was interesting to contrast them. Obviously, Chicago isn't a hub in the same way as Dubai and Singapore are hubs, but there are similarities.

My apartment in Dubai still isn't ready. It's starting to feel a bit like home, especially thanks to all of my friends there, but I'm sure I'll feel a lot more settled in when I have a my own space and all of my "stuff" moved in. Planning to spend more time there when it cools down again in the fall. ;-)

Uploaded my photos to Flickr and Picasa but going to try using Fotopedia widgets to post them here.

One of the groups in the Royal Film Commission Online Media workshop worked on a video of the workshop itself. There will be a more lengthy and hopefully Arabic subtitled version of the workshop going online after some editing by the RFC. This video is a student-made video which describes the workshop and the various groups and their projects.