Historically, the first communities were human tribes. A lot of challenges faced early tribes: How do you feed tribe members? How do you keep tribes healthy? People didn’t have community managers, they simply tried things and learned from what worked and what didn’t work. Tribe members didn’t set out to be community leaders, much like open source leaders didn’t set out to be leaders. Open source hackers that succeed in creating valuable open source projects become leaders because of their efforts and the same was true for early tribes.

Jono went on not to predict the future, but to share an informed trend: Community management is at a renaissance. The renaissance connected the dark ages with the enlightenment and people started to educate themselves. People created a repeatable science: If this happens and then you take that action, you can expect a certain repeatable outcome. For instance, the concept of people getting sick, then taking pills and then getting well is a great example of repeatability.

We’re seeing this happening with community management. We’re seeing a profession of community management come about. More people than ever before are working professionally as community managers; these people are the connection points between communities and companies. When we have repeatable community experiences, we want others to be able to repeat these community developments!

Jono underscored the key lesson in his keynote: We’re at the beginning of this community renaissance. We’re going to see a repeatable body of knowledge that will allow us to push communities forward.

Related:

• The long road toward the Community Leadership Summit

Programmer insecurities can hamper the progress of projects. Ben and Brian’s first tip for avoiding these insecurities is to “lose the ego,” which of course is easier said than done. They gave the example of the Apache Software Foundation, which practices a focus on the community and not on the code itself. This gives the project a strong community ego, which then limits individual egos from getting in the way.

“Criticism is not evil” was their next point. For instance, one person at Apple started a code review process, but after a week his manager took him to task since others complained that people were being too negative in code reviews. The team at Apple did not respond to the process well, since they were not used to critical review. Ben pointed out that open source hackers tend to receive more criticism than programmers in the closed source world, since everyone can inspect your code when its freely available. This gives open source programmers a thicker skin with which to deal with criticism and move on.

Embracing failure — unlike the adage that “Failure is not an option,” in engineering failure is commonplace. Doing something, even if you fail, is worthwhile since it provides opportunities for learning. If you allow yourself to fail, your code will improve over time — look at failure as an opportunity! Google believes that its good to “Fail fast.” If you embrace failure, then failing fast means that you can learn from your mistakes quicker and move on to write better code that won’t fail.

It’s important to not cover your tracks when you fail, suggest Ben and Brian. Your tracks provide you with the evidence of how you failed and how to learn from your failure. Brian said: “I hate it when Git users erase their commit histories to cover their tracks!” This goes back to the original point of ego — the perfect code didn’t simply pop into your head. All the little failures along the way provide key information about how your project evolved and they make you simply human.

Practice your skills. Brian practiced writing code on paper before his Google interview since he knew he would be asked to write code on a whiteboard or on paper. Having practiced this awkward task, he felt more comfortable during his interview (which he clearly passed, since he works for Google).

“Be a small fish.” If you never put yourself in a position where you’re scared, how can you grow as a developer? And “Be influenced.” If you want to be a leader, you need to be open to influence. Even the most effective leaders never have all the answers, so a good leader needs to take input from the other people on the team. If people on the team take turns being the leader, you can strengthen the team as a whole as well as strengthening each member. The last “Be” point was to “Be vulnerable.” It’s important to share your failures and admit when you’re wrong. People will respect people more who can openly admit their vulnerabilities.

Tools and how they affect collaboration and social behavior were Ben and Brian’s next topic. They reminded us that “You cannot apply a tech solution to a sociological problem.” For instance, access controls on version control systems are usually not needed. Project leaders should grant complete control, and if problems arise, someone should simply talk to the problem committer. Normally version control problems come from a lack of understanding the established methodology — people rarely commit code that they know violates the established methodology. The best fix is simple human-to-human communication, not locking people out of portions of the version control system.

Towards the end of the presentation, Brian and Ben asked about the right time to collaborate. Its clear that collaborating when you’re done with the project is too late, but when is the right time to start? If you start too soon, you’ll get too many people who will give input into a project that hasn’t fully formed yet — this can lead to chaos. Or, as SourceForge shows, if you start too soon, you may never get anything done, since there are thousands of dead projects on SourceForge that never committed a single line of code.

The sweet spot comes after the project has a concrete goal and scope committed to a web page, which makes it more “real” for new visitors. It also helps to have a coherent design document that outlines the basic architecture and layout of your project. But, what helps most is a proof of concept of the project — something that works but shows your direction and intentions. With a proof of concept, it’s possible for others to jump into your project and start contributing.

To conclude their talk, Ben and Brian summarized their points: Don’t try to be a genius! Collaborate early and often and pay attention to the tools you choose for your project. Also, pay close attention to the timing of your project and let yourself be influenced. If you do all these things, people may just think that you’re a genius!

Genius or not, I really like what Ben and Brian have to say. Thanks for another killer presentation!

The first talk I attended was: “Drizzle: Status, Principles, and Ecosystem” where a number of Drizzle developers shared their thoughts about this project. Brian Aker forked MySQL to create Drizzle a year ago with the premise to create a new database that was leaner and more extensible by using a micro kernel and plugin model. The existing MySQL codebase had grown overly complicated after a number of features were “hacked in” which made adding more features overly difficult.

The drizzle team, which has several developers sponsored by Sun, seems very much concerned about the technical nature of their project. As in most open source projects the developers seem less concerned with politics and companies and more with creating a kick-ass database. I tried to ask a few questions to see where they think that MySQL, Drizzle and MariaDB were headed, but largely the questions were not answered — they reiterated the focus on technical excellence. Aside from having serious corporate support, Drizzle appears to be driven by classic open source principles. This makes me happy, because the future of both MySQL and Drizzle are unclear since Oracle just purchased Sun. Given the focus on open source principles, I’m certain the Drizzle would not go away should Oracle decide to stop supporting the team.

The second session was: “MariaDB: Community Driven SQL Server” which presented Monty’s (of MySQL AB fame) new company Monty Program AB. Unlike the Drizzle group, Monty’s new company has clear corporate goals, complete with fluff and marketing speak. The new company’s fork of MySQL, MariaDB, aims to be 100% compatible with the original MySQL. Its designed to be 100% drop in replacement that goes even as far as letting people who are certified on MySQL apply their skills to MariaDB. Even though Monty Program AB differs in a few aspects from the original MySQL AB, it really seems to follow a fairly similar model.

The people working on the original MySQL were not too well represented here at OSCON. Unlike Drizzle and MariaDB, MySQL is shrouded in uncertainty since no one know what Oracle plans to do with MySQL. Given that it MySQL can cannibalize (and probably already has) Oracle’s flagship product, the future of MySQL is very uncertain. The mindshare at OSCON clearly belongs to MariaDB and to Drizzle.

Returning back to my original point now, we can see that the acquisition of MySQL AB by Sun hasn’t worked out at all how everyone had hoped. Many of the fears raised by my blog post from 3 years ago have manifested in this mess. After MySQL became a Sun property, the quality of MySQL started to suffer, including releasing a version of MySQL that had serious known bugs. This had never happened before and sent a clear signal that not all was well with MySQL. And the community had a lot of frustrations with Sun as Sun slowed or stopped accepting patches. Even important companies like Google had serious patches to MySQL ignored. Clearly the process had broken down.

Today we find ourselves with at least three versions of MySQL that all have differing goals, yet promise to share code with one another. Some will be compatible with each other, some break new ground. The one thing we know for certain that nothing in this game is certain. Until Oracle makes a statement about the future of MySQL nothing will be clear.

I find it really interesting that both Drizzle and MariaDB have returned MySQL to fundamental open source roots. Neither group is going to require fancy licenses or copyright agreements and will solely rely on using the GPL. Drizzle is devoid of a commercial model for the time being and even Monty Program AB will look like a more “classic” open source company.

Amidst this uncertainty the only thing that is clear to me is that the MariaDB and the Drizzle communities are not waiting for anything — they are working on new improving their projects as fast as they can. I personally think that Drizzle presents the most interesting approach to saving MySQL — it sounds like the codebase needed a serious overhaul in order to break some development bottlenecks and to allow more people to come and participate in the development process.

Even though I’ve switched to Postgres many moons ago, I’m utterly fascinated by what is currently happening with MySQL. The current events in this space are things that we discussed three years ago with the conclusion of “This will be interesting to watch!” Indeed, it’s interesting to watch — I think we’ll be talking about this situation for quite some time to come. Oh, and MySQL users: Worry not — you’re going to be the winners in this whole debacle!

First off, Kirrily quantified the gender imbalance problem for us: women make up only 1.5% of contributors to open source projects overall. They’re 5% of the perl community and 10% of Drupal. The IT industry has 20% – 30% women; clearly it’s a sad state of affairs that open source lags so dramatically. At least part of the problem can be traced to the culture of open source communities. Unfortunately, many open source communities share sexist jokes, and even here at the conference Kirrily saw sexist images in presentations. (Over lunch I even heard of an OSCON party last night where faux strippers were “dancing” for the party attendees. If that is true, it is indeed a sad state of affairs.)

Turning to more cheerful topics, Kirrily shared some success stories. The Organization for Transformative Works (OTW) is a “nonprofit organization established by fans to serve the interests of fans by providing access to and preserving the history of fanworks and fan culture in its myriad forms.” The OTW project boasts 60 thousand lines of Ruby code and 20+ coders who are all female!

She also talked about Dreamwidth, which forked the LiveJournal codebase to modernize, update, and streamline the project. Dreamwidth has 210,000 lines of Perl and JavaScript code with 40+ coders, about 75% of them female. These projects show that women are indeed interested in participating in open source.

So, why do so few women actually participate? Existing open source projects simply do not present an inviting atmosphere to women. When asked about not participating in open source projects, women replied: “I didn’t feel like I was wanted,” or “I never got the feeling that outsiders were welcomed…”.

Kirrily gave us a number of tips for how to get more women involved in our projects. First, recruit for diversity. The early project members set the tone of the project, so reach out to women from the beginning to make sure they help create the project’s culture. Next, set up a Code of Conduct that lays down proper and respectful behavior for the project — say it and then mean it. Then use tools to make it easier for beginners to contribute from day one — make newcomers feel welcome in your project. Transparency is also very important — show newcomers what your project is like on the inside and show them what it would be like to participate in the project. Value everyone’s contribution: code, docs, bugs. It’s all important — successful projects need more than just code. When someone contributes to your project, be sure to thank them and appreciate their efforts.

One tip that seems obvious, yet needs to be stated: don’t stare. Staring at people makes them feel uncomfortable and unwelcome. Also, call people on their crap: “If there is a naked lady on someone’s screen, then they are being an asshole.” Don’t be assholes!

Finally, pay attention! Most guys simply aren’t aware of sexism around them, so it may take conscious effort to spot things that can make people feel unwelcome or uncomfortable. Please watch out for sexist behavior and address it when it happens.

Kirrily closed with this thought: Any steps you take to include women in your project will only increase the total pool of hackers who can work on it! Well said. I’ve been keenly observing the gender imbalance at conferences for a number of years now and I find it enlightening to have Kirrily lay down the issues as she sees them.

Jono suggests that “Stories are vessels of best practice.” Whenever a community shares a story, it usually has a message attached to it–an anecdote that usually comes to some concrete point. Stories give community members a sense of purpose and belonging; he encourages people to tell stories in their communities.

He went on to talk about how open source communities are meritocracies. People in our communities rise to higher levels because of the work they do. In Ubuntu a volunteer can walk in off the street and, given enough hard work, they can rise to the highest level of the community, based on the work they do for the community. Communities are also economies–gift economies that work on patches, rather than money.

Jono tangented for a minute to remind us the we should review patches as if they were gifts–aim to avoid judging these gifts too harshly by calling them crap. Imagine waking up at Christmas and giving a gift to a friend who calls it crap and tosses it into the trash can. We don’t do this in real life, so we should avoid doing this in our open source communities. Jono returned from his tangent by pointing out that one builds social capital in a community by giving gifts, like patches. In my personal opinion, there are many forms of means of building social capital, not just patches. Telling stories and passing along the traditions and habits of a community are also great examples of gifts that build social capital.

Next Jono talked about “Quality of Aliveness” as a factor in building belonging in a community. He gave the example of seeing a 5 year old kid use Ubuntu and how he felt the hairs on his neck stand up. These visceral experiences give us a feeling of accomplishment and that our efforts in communities are worth our time. These experiences provide a strong sense of belonging to a community.

Jono’s next point illustrated that teams present vessels of belonging. For instance when you first build a team everyone is lost and no one feels at ease. But once you get to know your “local neighborhood” a little, you begin to feel comfortable. The key for building strong teams is to foster environments where people can feel like they belong and they know what to do. Provide advocacy, podcasts, translations, support, and put on local events–these all help contributors succeed and motivate them to stay involved.

Then Jono rhetorically asked how social capital in teams grows. The Ubuntu team utilizes karma in the launchpad web application, a hall of fame, highlighting people on blogs and in summits. Each of these elevate contributors a little to highlight their contributions. Teams need to build some infrastructure since most people need others to celebrate their contributions. Most valuable contributors don’t toot their own horns about their work–social capital grows most when teams have means to highlight the efforts of their contributors.

Social capital forms freely, says Jono. Its best not to push people into management jobs, but to let the community organize itself. For instance, social captial builds naturally through conversations in the halls of conferences like OSCON and during project meetings/summits. Sharing stories and introducing yourself to others helps build your personal social capital.

Strive to keep a positive attitude at all times, even when dealing with problems and criticism. Never start with “This sucks! You suck too!” Adopt an “I’m going to kick ass!” attitude–and people are much more likely to kick ass. People who have a glass-half-empty attitude (as opposed to half-full) can drag an entire community down. The team’s attitude carries a lot of weight–a project with a “kick ass” attitude can win a ton of mind-share over projects that have negative attitudes.

Jono closed out his presentation with an anecdote from the Ubuntu bug tracker: Bug #1 “Microsoft has a dominant market share” Sadly, this bug keeps constantly being deferred to the next release of Ubuntu. Ha!

Finally, he summarized by saying: “Please don’t be a Sheep!” Thanks for the many community insights, Jono!

]]> http://radar.oreilly.com/2009/07/oscon-building-belonging-in-co.html/feed 1 http://radar.oreilly.com/2009/03/etech-wrapup.html http://radar.oreilly.com/2009/03/etech-wrapup.html#comments Fri, 13 Mar 2009 20:07:36 +0000 Robert Kaye http://blogs.oreilly.com/radar/2009/03/etech-wrapup.html I’ve been attending ETech and the P2P conference that preceded ETech and this conference, and this year I’ve noticed the best gender balance ever. Granted this conference’s focus has changed from the very geeky P2P and Web Services focus it started with and meandered through a host of topics to arrive at a less geeky, but still thought provoking set of topics. I feel that this change in focus has made the conference more accessible to women and as a result we’ve seen the gender balance improve over the years.

I’ve also really appreciated the ETech Maker’s Shed where I got the chance to talk about iPhone hacking with Damien Stolarz. I talked with Brian Jepson on all things Make and what an impressive impact the Make has made on my less geeky friends. I periodically have my friends who discover Make come to me to ask me if I knew about this cool movement. I’m honestly proud to know some of the people behind Make.

Another thing that stood out at this year’s ETech was the consistent high quality of speakers — each and every session I went to kept me engaged with the presentation. It seems that at some conferences I tend to get lost in my laptop and after the conference wonder what things were all about since I never really paid much attention. Not so at ETech and especially this year — all the speakers captured my attention the entire time.

I also liked the scanning laser that made beautiful visualizations of the audience. I really appreciated hearing Zoë Keating play her Cello on stage while being video remixed with the laser visualizations. Two totally unrelated projects/people coming together to blending their craft to make an impromptu mash-up for the audience gave me warm and fuzzy feelings last night.

And, having ETech back in the Bay Area is also nice — I stayed with friends a few blocks away and biked to the conference in the morning. The arrangement was conducive to being rested and alert when I arrived in the chilly morning. And the Fairmont gave us lots of room, even if I felt that I kept walking in circles the wrong way to get to my next location.

I was really pleased with this year’s ETech — thanks for putting on the conference and thanks for letting me blog about it!

Tony Jebara’s presentation “Mobile Phones Reveal the Behaviors of Places and People” really opened my eyes to what amazing things you can derive from large data sets. Tony co-founded Sense Networks which specializes in taking GPS and mobile phone location data and deriving as much useful information as possible from it. Sense Networks works with mobile phone service providers who collected data from users who opted in to have their data be collected and mined. All the data they receive from the service provider is GPS location data — no personal information at all was ever made available to Sense Networks.

Using mobile location data passively, the goal is to build a more realistic Facebook. More realistic in the sense that it should mirror real life connections and not the 2000 random friend connections you might have on Facebook. Based on mobile phones co-locating, Sense Networks hopes to deduce a real life friendship and then enable intelligent online applications.

For instance, Sense Networks can can deduce the activity of bankers in the financial district of San Francisco. Given that a cell phone moved to the financial district in the morning and stayed there for 8 hours, they assumed the signal came from a banker. Associating signals to movement patterns allow Sense Networks to start correlating the DOW and when bankers arrive at work. Apparently when the DOW is up, bankers are more likely to head into work sooner, but when the DOW is down, bankers are likely to take their time getting to work. Tony’s team can also correlate between night life and the health of the DOW — when the DOW is healthy more people move from work to popular night time spots, and less so when the DOW is down.

The next thing that Sense Networks wanted to figure out is where similar people to you might be. Tony suggests that if you build a network of people based on co-location data and examine the location at which people congregate you can start to group people into like minded tribes of people. To do this, Tony’s team needed to build a network of places that determines the flow of people in and flow of people out of a place. Commerce information of what types of business are located in a given location and demographics for a location give away a surprising amount of information about the people who frequent those places. This information then allows Sense Networks to determine what is happening on any given street corner.

Putting this data into a matrix of hours in a week and probabilities of a user engaging in the various activities yields many interesting results. For instance, you can deduce a lot from a person simply by looking at where the person sleeps at night. Do they sleep in a wealthy, single or family neighborhood? Or, if a person hangs out in wealthy neighborhoods, but lives in a poor neighborhood you can deduce a certain aspirations of the user. This type of analysis yields a very general model of people and Tony emphasizes that the personal data on any given user is discarded and that only general trends of behavior are sought.

I find it fascinating that these kinds of trends can be deduced from GPS, commerce and demographic data. While I find the technology and data clustering algorithms that enable these features very interesting, I have to question how the results will be used. Tony assured the audience that their customers will use the data to better target advertising, But I already have enough pesky advertising I’m working hard to ignore — I’m not certain I need more targeted ads bombarded at me. But there are loads of scary applications for this data as well — the number of Big Brother type applications enabled by this scare me.

Regardless of how this turns out, I really appreciated Tony’s presentation because it enlightened me to some of the possibilities of mining large datasets for valuable nuggets of information.

However, the science world hasn’t created efficient means of communicating knowledge as the net did for more general topics. So far, the science world has taken paper metaphors and made them digital, which doesn’t really enable new models of easy data sharing. John likened the scientific community to a stable system that has an “immune response” that is resistant to change. Prohibitive license agreements and patents create chilling effects that prevent efficient communication means from evolving.

John says that in the scientific community “there is no crowd”. On the net in general one can apply concepts of Wisdom of Crowds to all sort of problems, but the knowledge required to participate in scientific crowds is uncommon. This fact creates significant barriers to entry to create the types of innovations that we commonly find on the web. Creating a science commons presents a clear goal with clear benefits — open rights provide for a multiplicity of incentives. Commons become the infrastructure of innovation as we’ve seen on the web.

But sharing is hard, John says. If you want to share you have to make sure you have the rights to do so. In scientific communities you need to worry not only about copyrights, but also about patents and privacy. For instance, when a company wanted to give away a new strain of rice with increased Vitamin A to prevent blindness caused by Vitamin A deficiency, it took an amazing 4 years to give the rice away. In that time countless license agreements and patents had to be cleared before the rice could be given away.

And even once you have rightful access to data, you need to teach computers to understand things — computers need to understand the relationship between ideas. This is why people in the linked data space have started making knowledge addressable by assigning URI’s to knowledge. By making knowledge addressable you can start expressing relationships between the concepts. The end goal here is to bring the benefit of the web to databases. Right now you can’t add Facebook-like apps to your data, but FreeBase has started working on that.

Creating innovations commons for scientists is hard, but not impossible John says. There are no one-click concepts — instead if you want to work with stem-cells you need to negotiate a complicated license agreement. Once you finally have that, you need to start at the beginning and make your tools. Imagine if you wanted to cook a meal and you had to start by making your own cast-iron skillet! But some groups have some progress — for example the open access movement has managed to get over 1000 journals released under a Creative Commons license. Then, some scientists have figured out how to play with each other without lawyers and created zones of certainty where they know they are are in the clear when it comes to legal restraints. And scientists who cheat the system can expect to be punished in grant committees and peer reviews. One such area that John mentioned is the Proteome Commons.

Scientists have started working on expressing their data and knowledge in RDF. Unfortunately RDF presents many challenges and makes life quite a pain, but in the end the interconnection between the data makes it worth it. People have started to create ontologies for many scientific areas and its becoming possible to make structured queries of this data. This linked data allows for the construction of much more detailed queries that give more refined results than a Google search with a similar text-based query would. Structured data leads to collaborative question answering and this can save vast amounts of time to many people.

Finally, John shared a story of how open data can lead to pleasant surprises. A group of science hackers ignored the terms of service on a web site that offered a visualization of data and screen scraped the data. Then they proceeded to mash up the data with the Google Maps API and created a page that allowed the side-by-side visualization of the data. The hackers then went back to the company whose terms of service they ignored and showed them the mash up and managed to convince the company to open up the data. But, this concept isn’t really new to anyone who believes in open systems. The Open Source world has shown us that great unexpected things can happen when you open your source code to the world.

I found John’s talk quite interesting since I’ve been thinking about linked data concepts for a number of years now. With stars like Tim Berners-Lee taking on linked data concepts as his new mission we’re going to see much more useful and intelligent data emerge in the coming years. So far, the linked data killer application hasn’t appeared yet, but after hearing John’s talk, I wouldn’t be surprised if the scientific community comes up with the first killer app.

Thanks for the great talk John!

In order of importance:

1. Cities: Cities overall were the number one issue that topped most of the sections Jer covered because they concentrate so many of the other points in one space. If green entrepreneurs could focus on improving cities in general, the most can be accomplished with the least amount of effort. Cities produce vast amounts of pollution, but also account for large amounts of energy consumption that may not be readily apparent. For instance, materials used to construct roads and buildings make up a large amount of the material flow in the United States. For the details on improving cities, see buildings and transportation.

2. Buildings: Improving buildings takes on many facets. Wasteful heating and cooling contribute a significant amount of lost energy, but even how and what materials we use to construct buildings has a great impact on the environment. Reusing materials from old buildings in new buildings can reduce the amount of energy wasted in creating new buildings. Creating new buildings that use less energy for heating and cooling could make cities drastically more efficient.

3. Transportation: Most of us understand that transportation contributes significantly to negatively affecting our environment. Clearly cars in cities make up large portions of environmental impact, but Jer points out that its better to share an existing car than to attempt to make newer cars more efficient. Having one car be shared between many people is vastly better than many people each driving their own slightly more efficient vehicle. Also, building new cars contributes greatly to the environmental impact, since vast resources are consumed in the creation of one single vehicle.

4. Food & Agriculture: The creation of food and agriculture also contribute significantly to the impact on our environment. For instance, humans personally consume 8% of all water and industry uses 22% of the water. But agriculture accounts for the largest chunk overall with a whopping 70% consumed. And the worst is that only about half of the water used in agriculture gets used — the rest escapes unused! Meat is also a large culprit — one pound of beef takes thousands of gallons of water to produce, whereas chicken takes only a fraction of that. Finally, agriculture represents one of the largest sources of water pollution with fertilizers contaminating drinking water.

5. Electricity generation: Producing electricity pollutes the environment significantly since a lot of power plants use coal as a fuel. While direct emissions from power plants present a large portion of the problem, air and water pollution associated with mining coal for power generation also factors into the equation. Mining operations have a huge impact by contaminating water and then the surrounding environment and generating more waste than any other process on the planet.

6. Family planning: Most people don’t think about family planning when they think green. But, family planning directly affects our overall population and overpopulation of our planet has taken a great toll so far and continues to get worse. Curtailing population growth can significantly reduce the impact that humans will have in the future — fewer humans, fewer resources consumed and less pollution.

7. Empowering women: Giving equal rights and access to education for women has been shown to drastically reduce birth rates in third world nations. Furthemore, Jer noted that micro venture capital organizations have learned that men are less responsible in repaying loans and that some organizations have stopped lending to men altogether.

8. Other industries: Industries such as chemical production, paper manufacture, concrete production and manufacturing electronics have great impact on our environment. Jer suggested that eliminating paper entirely and using more digital solutions can have a serious positive impact. Also, manufacturing electronics requires precious metals like Indium which do not exist in abundance in the earth — Indium will likely be depleted from the earth very soon and must be recycled in order for it to remain available to us. Finally, the disposal of electronics presents another massive problem: A lot of the chemicals used to manufacturer electronics and the batteries that power them are toxic.

Thanks for all the valuable information and thanks for prioritizing and putting the dangers that affect our environment into perspective, Jer!

The first session I’d like to share with you was Toby Segaran and Jesper Anderson’s “I Just Don’t Trust You: How the Tech Community Can Reinvent Risk Ratings” presentation. Toby and Jesper posited that the system for rating credit instruments is horribly broken. Right before Lehman Brothers crashed, Moody’s credit rating agency gave Lehman Brothers a AAA A2 credit rating. Moodys immediately down-rated Lehman Brothers after they crashed — a little too late! Jesper and Toby outlined four reasons why the current system fails to do its job:

1. Payments create bad ratings. NRSROs (Nationally Recognized Statistical Rating Organization), like Moody’s, S&P and Fitch all take payments to rate a given financial instrument and this incentivizes these companies to create false ratings. The structural problems that allow these conflict of interest transactions to occur beget a host of moral failures. This behavior amounts to bribery that doesn’t send anyone to jail.
2. Opacity creates bad ratings. Credit rating agencies enjoy patent-like protection in the US, but without the requirement of public disclosure. They can operate on whatever principles they choose, which leaves their rating system nearly meaningless. What does a AAA rating mean? The current system makes an AAA rating no more effective than a gold star that might be awarded in grade-school. A closed consensus model doesn’t explore alternative options and it gives to the question if the current risk models are suitable for doing their job.
3. Lack of ecosystem create bad ratings. Today’s market ignores good predictions only to celebrate them after the fact when the market starts crashing. We need to incorporate changing knowledge of the market into the models and constantly evolve them. Creating an ecosystem that can review financial information in broad daylight and encourage a greater accountability will create a more robust and accurate credit rating system. Its important to remove the incentives for secrecy.
4. Single source of information creates bad ratings. A single viewpoint of financial data is too narrow to do justice in the complex market of credit ratings. Any and all sources of information need to feed into the model for the greatest chance at success. The current model encourages blind thinking, when credit ratings should focus on analyzing as many sources of data as possible.

With the problems defined, Toby and Jesper propose the following requirements for a new credit rating system:

• Ratings need to be accessible. Credit ratings need to operate from an information commons. Debt is about trust — a Digg style system won’t work here.
• Ratings need to be open. Everyone needs to be able to see the complete view of the landscape.
• Ratings need to be diverse. Many people need to take part in credit rating. Any new system needs to be built as a Bazaar, not a Cathedral!
• Ratings need to be transparent. Transparency is a vital component in a new system — opacity only hides the shady practices of incumbents and prevents the system from really working.

And rather than ranting without substance, Jesper and Toby have been working on a new system at Freerisk.org that acts as a specialized front end to the FreeBase database. Based on Open Data principles, FreeBase contains public SEC records (among many other data portions, including the MusicBrainz data). FreeBase exposes the SEC records in RDF via a public API, which makes accessing SEC data much easier than before.

Jesper and Toby invite the general public to come and take part in this nascent project — they hypothesize that by exposing the data to more people, anyone can create a risk calculator. And of course, if everyone tried to create a new risk calculator, we’re bound to find new models that work better than the current models that allows financial catastrophes to happen. They conclude: “With a little help, we believe that we can beat the NRSROs!”

If the current financial crisis bothers you and you feel angry enough to help look for a solution, go visit freerisk.org. Thanks for the informative talk, Toby and Jesper!

]]> http://radar.oreilly.com/2009/03/etech-i-just-dont-trust-you-ho.html/feed 18