Category: Mozilla

Science Foo Recap
This weekend I went to Science Foo Camp, also known as “Sci Foo.” This was an extension of the “Friends of O’Reilly” camping events (“Foo Camp”) that the O’Reilly publishing folks have held for the last couple of years.

Foo Camp is an invitation-only event at the O’Reilly facilities in California (and leter expanded elsewhere) where one literally camps out for the weekend (in cubes or by pitching a tent on the lawn or in the apple orchard). O’Reilly makes meeting rooms and meals available, and sets out a large grid showing meeting rooms on one access and time slots on the other. The event starts with an initial gathering where everyone introduces themselves. Tim O’Reilly’s rule is: you get to say your name, an organizational affiliation, and 3 words (literally, 3 words) to describe yourself. After this, the content and events of the weekend are up to the participants to decide. It’s a “conference” created by the participants on the fly. Naturally, a lot of the great stuff also happens outside of any particular session. Foo Camps have been focused in the software and technology space. Not entirely, but that’s been the focus.

Science Foo was different. Its focus was -– no surprise -– science. It was organized by O’Reilly and Nature magazine, and hosted by Google at Google’s Mountain View campus. The idea was to gather interesting people who didn’t necessarily know each other or work in the same field, but were open to cross-fertilization and new ideas. No camping this time, but a bunch of folks in the same hotel generating late night discussions.

As you might imagine, the combination of O’Reilly, Nature and Google assembled a fascinating set of scientists. This included biologists of all sorts, chemists, physicists, earth scientists, clinicians, historians, technologists, science fiction writers and a set of people interested in large data sets. The topics ranged from the physics of light to gene expression to citizen science to emergent evolution to the politicization of science to open science. Here’s what the Saturday schedule ended up looking like.

The O’Reilly folks also invited a few of us involved in open source projects. The idea was to bring some of what we’ve learned in opening software development to the efforts to make science more open and collaborative rather than focused only the fierce secrecy required to protect IP and publish first. It was great fun to go because today’s science is utterly boggling, it’s a joy to find groups of interesting people, and I would like to see some ways to promote more openness rather than intellectual property protection in science.

I noticed a set of things were different right away. First, I was surprised at how many people posted to the wiki before the conference started describing discussions they would like to lead. I had thought that since the format was new to many of the participants it might be slow getting started. But there were probably 50 ideas posted before anyone arrived in Mountain View. And when it came time to pick a slot on the schedule people were not shy either. Later I realized that many of the participants have made their career in writing and presenting their results and that they are very accustomed to making presentations and leading discussions.

Some other things that stood out:
- Many people were unable to describe themselves in the allotted 3 words. A bunch of people managed to hypenate words into phrases and get them counted as 1 item (“data-visualization techniques” for example), and a bunch more needed complete sentences.
- The average age was much higher, at least 10 years and maybe 15 years.
- The number of people who came with presentations was high.
- The rapid-fire, high interruption, bounce around the room discussion of Foo Camp was much more measured and deliberate here. Not necessarily less effective, just different.
- The sense of people just starting to get to know each other was much stronger. At Foo Camp a bunch of people know each other already. This was less so at Sci Foo. It was the first one, and the people came from a very broad set of disciplines and much of the weekend was learning enough about other people for a discussion to emerge.
At the beginning most people went to the sessions. As time went on, and especially on Sunday, the open space was more and more filled with people who had come across an interesting idea and had settled down somewhere to keep discussing it. The sense of people creating conversations and connections was palpable on Sunday. It was as if Friday and Saturday set the stage, Saturday night a bunch of folks started to connect and by Sunday people were wildly open to new ideas, new people and new connections.

The closing session was surprisingly lively. Maybe I’m used to Foo Camp where a bunch of people are up most of the night and everyone is a zombie by Sunday afternoon. I don’t recall a closing session at Foo Camp; maybe I’ve just missed them all !!! But the Closing Session at Sci Foo was well-attended, lively, full of ideas and a good gathering in itself. One person wanted “real-time intelligence” on what’s happening in other sessions so he can constantly evaluate if he’s in the right place. (What’s the noise level in other sessions, can we tag people’s cell phone so we know who is in other sessions, etc.) Someone else replied “no thanks, the best part has been wandering into the wrong session. Or finding a session cancelled but talking with whoever showed up about other things.”

We had a few discussions about how the lessons of open source software might be useful in “open science” but this was just a beginning. I’ve got a bunch of ideas about this that I’ll try to get written down and posted shortly. Tim was clear that most of the people at Sci Foo won’t be at the next one (assuming there is a next one) – the goal is to mix people up so they can’t keep inviting the same folks back. But whether or not I’m there, I’d like to see the discussion of bringing (and retaining) openness and collaboration to scientific research bear fruit.
August 16, 2006
Catching Up with July

In July I mentioned a couple of projects that are now underway. The beginnings of Mozilla “prototypes” can be found at labs.mozilla.com. It’s in the early stages, which is the perfect time for good ideas to carry weight. So take a look and see if the early phases capture something in your imagination.

Separately, Seth Bindernagel has plunged in to get our Community Giving program underway. I said I would describe what we hoped to accomplish in more detail, but Seth has done this better than I could, so head over to his blog to find out where things stand.

August 14, 2006
Mozilla “Prototypes”
One of the issues I see regarding our products is the tension between being cautious about changing our products on the one hand and trying to innovate on the other. There are good reasons for this tension, since each perspectives represents part of our current reality.

There are a number of reasons to be cautious about changing the product. We have a great product that people love. We also have a userbase of many tens of millions of people; a good portion of whom prize familiarity. Many people struggle to understand the difference between browser windows, search engines, software, data and the Internet. Constantly changing software can be disconcerting. And all of us are determined to avoid “software bloat” – the practice of adding new features simply for the sake of adding new features.

On the other hand, continued innovation is critical. People are using the Internet in new and ever-changing ways. People continue to look for information but they also communicate with each other in a growing variety of ways. Some of these ways are already browser-based, such as the creation of identities in social networking sites and the sharing of information about oneself. Others are not currently browser-based, such as instant messaging, but provide data about what people want to do online.

User activities are expanding. The integration between software and web services is young. Firefox cannot stand still and remain equally useful as people do more things through their browser. There are plenty of ways to improve user experience left to explore.

It’s also expremely important to have some key actors in the developing Internet ecology focused on public good rather than private gain. The Mozilla project has a unique ability to do so. Our public benefit mission, our central focus on user experience and our vibrant, engaged community make us a unique and important element in the changing Internet landscape. This is true of the Mozilla project and our technology as a whole, and it is true of Mozilla Firefox as well.

We need to try new things to see what the Internet and browsing experience can be, could be, should be. We need to try things that may fail. We need to experiment with new ideas before we know if they should be included in a general product release. Trying to do this in the main development process is extremely difficult. This main development process is highly optimized toward building stable, shipping releases. The code in this world is verified every night to make sure that new code added in the previous 24 hours meets a set of requirements and doesn’t make it too difficult for other developers to work. This is an excellent process for its stated goal. But it is a very difficult system for trying out new paradigms. It’s hard enough to be creative about how to help people use the Internet. It’s many times harder to do so within our existing product constraints.

So we need a mechanism to work on new ideas that is separate from our main development process. This is important enough to devote some resources to this, and I’m setting that in motion now. Its ultimate success will depend on the community reception, participation and leadership, like everything we do.

The basic idea is to provide a development forum to explore a small number of ideas that could provide new classes of functionality or other significant changes for our products. Our initial focus will be heavily in browser-based activities, though that isn’t set in stone and may expand with time. By “new classes of functionality” I mean things like improving browser interaction with social networking activities; more integration with web services; what could one do if one could had local storage of data from browsing activities? A fuller list of potential projects can be found at: http://wiki.mozilla.org/Mozilla_Prototypes#Process

We will start with a small number of projects because part of the initial goal is to focus attention on promising categories. The goal is to have this be a broadly-based effort where a range of people / organizations can explore ideas with the Mozilla community. We hope many of these projects will be led be people with no formal relationship to the Mozilla Foundation or Corporation.

The general goals are:
- Identify areas where exploration is important
- Determine if and who has expertise and interest in leading this exploration in our world
- Select a handful of projects
- Provide development tools, forums, etc.
- Direct attention of appropriate parts of Mozilla community to Mozilla Prototype projects.
- Be aggressively innovative;
- Eliminate Stop Energy
- Expect many ideas will morph to become useful
- Recognize some ideas will be dead-ends
- Harvest useful ideas into core development
For now, we’ve been calling this initiative “Mozilla Prototypes.” I picked this word as a starting point because I wanted something that doesn’t have as much acquired meaning as “Labs” or “Research.” It turns out that “prototypes” has been a useful starting point in that its use revealed a real interest in creating prototypes. But the initiative should be broader than that; going far enough into implementation to learn if something makes sense in the core of Firefox.

Mozilla “Prototypes” needs someone to guide its development and get it off to a healthy start. There’s a lot to be figured out -– who and how do we decide on a project, when is a project over, what other related activities make sense. Basil Hashem of the Mozilla Corporation has offered to take on this role and get Mozilla “Prototypes” started. Basil has a product management background, and has a great set of skills to get Mozilla “Prototypes” off to a good start and develop a framework where exciting things can prosper.

Basil led an initial discussion of Mozilla “Prototypes” at the brainstorming discussions in Mountain View the last week of June. (Those discussions were open to the Mozilla community, but of course there are only a few people close enough to drop in, and telephone conference calls are difficult for many.) There were a number of logistical questions, particularly about how we’ll decide on the first projects and get things going. These first set of decisions will probably be made by people very closely involved with Firefox. If it turns out we need an individual final-decision maker then I’ll identify one. I’d like to start with very low process requirements and add formality as we go along. That way any formal rules we come up with will be based on experience and actual data.

Basil has an initial description on the Mozilla wiki at: http://wiki.mozilla.org/Mozilla_Prototypes. Please take a look and add your thoughts. If you feel a wave of Stop Energy, please take a deep breath and see if it diffuses. If it’s still there, please address it to me rather than Basil. On the other hand, if you’ve got ideas and can help us make Mozilla “Prototypes” more successful, then please by all means get in touch with Basil, or both of us.
July 10, 2006
Welcome Seth Bindernagel

In early June I noted that we had found a great person to lead development of a grants and donations program and that we would turn to this topic in mid-July. That person is Seth Bindernagel, we’re coming up on mid-July, and Seth joins us at the Mozilla Corporation today.

The goals of the program are to help strengthen the Mozilla community. They are not to turn volunteers into employees or to reduce the number of employees. We’re not looking to be an all-purpose grant–making organization, or to be gigantic. The point is to use all the different kinds of resources available to strengthen our community, and that currently includes some financial resources.

Seth will join us for an initial 6 months to flesh out how this might be done, to try an initial set of programs and develop a clearer view of our path before joining us permanently. The focus is not on making a big bang, but on doing useful things. Seth and I spent some time articulating this work more clearly. I’ll post this separately, since this welcome is long enough already.

This is an unusual role. We are lucky to have found Seth, whose background in business and social entrepreneurship matches remarkably well. Seth comes to us from the Haas School of Business at the University of California. While there, he focused on socially responsible business, co-leading the school’s Net Impact Club and serving as co-chair of Judging for the Global Social Venture Competition. He was also a member of the winning team for the Global Ethics Challenge. Before business school Seth spent three years working with Ashoka, a global nonprofit organization focusing on advancing the profession of social entrepreneurship.

At Ashoka Seth served as the Program Manager for the U.S. and Canada programs. With the team, Seth helped search for and select leading entrepreneurs in the U.S. and Canada who were creating new ideas to solve critical social problems. He helped launch Ashoka’s Accelerator for Social Entrepreneurship, which brought together Ashoka’s corporate partners Hill & Knowlton, McKinsey & Co., and the International Senior Lawyers Project with Ashoka Fellows in need of pro bono professional support. These partners donated their time and industry expertise to Fellows who were starting new organizations with strategic development needs. Seth helped organize all orientation and induction programs for the new social entrepreneurs entering the Ashoka Fellowship. Seth has consulted many different social ventures during his time at Berkeley, including the Omidyar Network, Ashoka, World of Good, and the San Francisco Giants Community Fund.

Please help make Seth feel at home. Feel free to ask him about his experiences, about why he switched his undergraduate degree from engineering to “Agriculture, Resource, and Managerial Economics,” about sports in general and baseball in particular. Please make some time to help Seth get to understand the Mozilla project so he can do more sooner. Seth will have a Mozilla related blog up and running shortly, I’ll point to it.

July 10, 2006
Layers of the Onion

A few days ago I mentioned the need for positive reinforcement to encourage creativity; Ben Goodger noted the prevalence of Stop Energy (a Dave Winer term) and the need to do something about it.

Two obvious responses are: Stop Energy wins, and the status quo resists attempts at change. During his visit to the Mozilla Corporation Bob Sutton has noted how disastrous this is for most organizations. We’re no exception. Another possibility is a determined individual who ignores all comments and plunges ahead, “knowing” that s/he is correct and change is better. I’ll call this the “Loner” approach for now.

The Loner approach addresses the Stop Energy problem but has many problems of its own. For one thing, the Loner approach is hard on the Loner. He or she must have a very thick skin, must proceed based on s/he thinks without listening to others (including possible improvements), and then must somehow be demanding or threatening or otherwise forceful enough to pull the project along. This is exhausting. The Loner approach is hard on everyone else as well. Bull-headed, demanding people who don’t listen to others are usually difficult people to work with. The Loner has to be really, really, really good to make it worthwhile for others to stomach the trauma. Our strength is the caliber and dedication of people who choose to work with the Mozilla project; encouraging difficult behavior to avoid Stop Energy is an unhealthy setting.

Also, if people get into the habit of believing they are always right and don’t need to listen to anyone else, then all sorts of unpleasant things generally follow. Few people are always completely right. It becomes hard to work together. People become zealots. Moderating influences are lost. Our experience has been that the group intelligence within the Mozilla project is very high; far greater than the intelligence of any one person.

So, how to encourage positive feedback for creative ideas, make use of our group intelligence and avoid Stop Energy? I think many of us use an approach I think of as “Layers of the Onion.” It’s a pretty simple idea. When someone has a new idea, s/he thinks it through a bit, then goes to a group of people he or she thinks of as likely to have the expertise to be helpful and the sense of possibilities to be encouraging and make good suggestions. At some point w/he includes people with a sense of the constraints as well to get a reality check. Feedback (positive and negative) is received and incorporated into the original thinking; maybe some implementation work is done.

Then the idea is discussed with a larger group of people. More feedback is received and incorporated. The idea appears in a public forum for public discussion and review. Maybe the idea never gains traction, maybe it needs more work to be generally acceptable, or maybe it’s time for implementation.

There’s nothing too complex or original about this process, I suspect it happens all the time. I’ve called it out explicitly because I believe that –- properly implemented of course — it’s an approach that meets our criteria of openness and transparency while simultaneously helping to minimize Stop Energy. I’m very focused on doing both of these things well, both for the project as a whole and for the work I need to lead on issues of Mozilla identity and governance.

July 5, 2006
The Big Picture — Part 3

Here is the last part of Mike Shaver’s summary of the July 4, 2006
Positive Reinforcement for Creativity

The discussion Bob Sutton lead at the Mozilla Corporation was also very helpful in thinking about the need to find people who can see and encourage the possibilities in a new idea. This grew out of a discussion of risk-taking and trying new things. In particular, the need to be careful about changing our products too drastically while at the same time encouraging innovation and responding to changes in how people use the Internet.

The discussion with Bob helped me see this in more general terms. Creativity needs encouragement. It’s not that easy to generate relevant new ideas. Brainstorming, encouragement and a sense of potential are needed to foster creativity. But it’s often hard to see the possibilities in an idea someone else has come up with. And it’s very easy to be critical and to think of all the reasons something won’t work. Put these together and it’s easy to end up with a situation where new ideas seem nearly impossible to implement, require too much change to even think about, or just not worth the risk.

So having a group of people to test out new ideas and see something other than the difficulties is important. Of course, many people do this informally, testing out ideas on growing circles of people. Some organizational awareness and focus on this can also do wonders. The Mozilla project has some obvious groups for trying out new ideas — module owners, super-reviewers, the peers for a particular module, etc. Most of these are code specific, and few of these address ideas across code modules. Also, there are an entire range of questions related to the products (in addition to the underlying code) for which we don’t have obvious “seed” groups for thinking about new ideas.

Sometimes I hear people say that all ideas should always be in a public forum such as a newsgroup and that all discussions in selected smaller groups should be avoided. Now I have a better idea of why this hasn’t seemed right to me. Some ideas get no response in these forums. And these forums suffer from the problem that it’s much easier to criticize than to see the possibilities in a new, unformed ideas. And sometimes the loudest, most aggressive responses get the most attention, regardless of whether they are the most thoughtful, knowledgeable or rational.

I absolutely agree that public discussions are critical in open source projects, both in getting information to make decisions, communicating decisions and archiving the thought process that lead to decisions. That doesn’t mean that each that each germ of a new idea needs to be launched into the public as the initial method of thinking about it. Sometimes a small group of people with expertise and the ability to see possibilities among the constraints is a fine place to start. They keys are to get the discussion to ever broadening groups of people and to a public discussion at the right time, to be open to criticism and change of plans at all stages, to have a good ultimate decision-making process and to get records of rational eand decisions in a public pace.

This fit in well with the project currently and probably temporarily known as “Mozilla Prototypes”, which I’ll write about shortly. It also spurred my thinking about the types of groups that would be helpful in questions of Mozilla project governance. I’ll write about that soon too.

July 1, 2006
Organizational Impossibility

Earlier this week Bob Sutton came to talk with Mozilla Corporation employees. Bob is a professor in the School of Engineering and in Organizational Behavior at Stanford, part of the founding team of the Stanford Design School, and the author of a number of books about organizations and their behavior.

June 29, 2006
The Big Picture — Part 2
Here is the first half of Mike Shaver’s marvelous summary of the discussions relating to Mozilla project goals held at the Mozilla Corporation in the spring of 2006. (More info about these discussions can be found in my summary discussionof this topic.) Mike outdid himself in capturing the themes of these discussions, and deserves greats credit for taking this on. I’m of course responsible for any problems 🙂

Major Themes

1. Our Work and Legacy Transcends the Browser

This was a nearly universal sentiment (possibly, in fact, universal, but my notes don’t permit me to be certain): what we are doing with the browser is vitally important to the future of the web, but what we are doing as a project and the technology that this project is building has ramifications that go well beyond that. Exactly where the project and corporation should invest to extend that influence is not a well-agreed point (see below), but that the browser is not the whole of what we do was not controversial.

Of the areas in which we hope to have a lasting effect on the industry and the world, some representative sentiments were:
- “Kept the web open, making the Next Thing possible”
- “Showed that open source can product great products, not just great technology”
- “Built and sustained a culture of software development focused relentlessly on real people”
- “Showed that open source and business can be mixed to the ‘benefit’ of a public-good mission”
- “Grew, nurtured, and deserved a strong and energetic community of supporters and contributors.”
The openness of our communication and, of course, software licensing were seen by many as critical to our ability to achieve a lasting legacy. That the artifacts we produce — applications, platform software, records of decisions, organizational processes, business models — will remain for others to build upon even if our project or Corporation should cease to exist is itself a key part of what we do and how we do it, and not just a side benefit or tactical decision.

(An interesting intellectual excursion briefly explored if it was even *possible* for the Mozilla Project to cease to exist, while people continued to use our products and technology and such. Ended in a draw, I believe.)

2. The Need to Appropriately Balance Focus and Diversification

Unsurprisingly, a frequent topic of discussion was how we should balance efforts directed towards leveraging Firefox’s current opportunities and success with investment in other applications (such as Thunderbird, Minimo, or Sunbird/Lightning), or “generalized” technology (such as XULRunner or embedding support). While there is not widespread agreement about the relative value of different tradeoffs, it seems that we largely agree that the managing of such tradeoffs is an important factor in the direction of the project and Corporation both. Also, it was frequently expressed that guiding people in these sorts of tradeoffs should be an important goal for the mission

Discussion and positions on the issue itself were predictably wide-ranging:
- How many different things can we (project, or Corp) manage successfully?
- We should be ready to undertake things that are not as clear to us as “the browser” is today.
- Related: if we were to start today without the history of Netscape’s source release, would we still be building a browser?
We should devote whatever we can to driving Firefox forward, lest we lose the window of opportunity.
We should not put all our eggs in the Firefox basket, and should “share the wealth” with other related projects and areas of work.

Related: is it easier to “convert” success with Firefox into opportunities in other areas, or vice versa?

How much of the “rest of the internet” (VOIP and IM were common examples) will be affected by our current work, and how much is outside of our influence as we currently operate?

Do we want to encourage more services to be brought into “the content area” via web services, discourage that trend, or remain neutral?

3. “Choice and Innovation” Is At Least As Hard As It Sounds

Whenever the conversation turned to our motto of “choice and innovation,” there seemed to be agreement that it was not concrete enough to be a useful guide in many areas. In particular, the opportunity cost element of choice, as reflected in the previous section, was felt to be especially troublesome. But for all that “C&I” is in sufficient to guide the bulk of our work, most felt that it was a good starting point for determining what the project could and should undertake.

As noted in the overview of the “legacy” threads, the innovation element here was widely and strongly believed to extend beyond “mere” product and technology choices. The organizational, fiscal, and social innovations that the project produces are clearly an important element of our work as a project and as a Corporation, and areas in which people wish to see us continue to invest effort.

Another common thread was that of “indirect innovation.” Whether through packaging our technology for others to use, improving the viability of standards on the web, or demonstrating a “third way” open source/business model, many of us believe that work to help *others* innovate was as important as innovation that we perform directly. (Several people mentioned that the changes in IE7 were an example of this indirect innovation, albeit where we helped create demand for improvment rather than the improvement itself.)

“Choice” is of course no crisper than “innovation” in its impact on specific decisions, but virtually everyone agreed that “choice of browser” is not the only interesting choice for us to work towards. Whether choice of operating system, choice of device, choice of language, or of interaction independent of disability, though, most expressed that the user’s choice was paramount. One person remarked specifically that “putting it in the hands of the user makes [choice and innovation] real”.

Our success in providing the user with meaningful choice is something that’s hard to assess (let alone measure quantitatively), and several people asked what we could use other than browser market share to track our progress there.

Finally, how would a future in which Firefox’s success brought it to 50 or even 90 percent market share affect our pursuit of choice? Would a Firefox hegemony be better than the IE one we’ve been working to break? Would we be as happy with a browser market (for instance; as always, the discussion was frequently about non-browser domains) carved into ten equal slices as into three [or four]?

June 26, 2006