Posts Tagged with “open source”

Last week at an Open Source Digital Voting Foundation event I had the chance to meet Debra Bowen, the California Secretary of State. The Secretary of State is the elected official responsible for the integrity of the electoral process — making sure that our voting system is accurate and honest and counts every vote correctly.

After talking to Secretary Bowen I ended up quite happy that she was elected to this role. Secretary Bowen is deeply interested in transparency, openness, and privacy. She is also a strong advocate for using open source software as the basis for digital voting equipment. Not long after she was elected she commissioned an independent review of the reliability of voting equipment and the auditing process, and found some disturbing facts. She’s been active in trying to fix these to bring more accuracy and trustworthiness to our system.

It was really fun to meet an elected official who understands implicitly that software code can effect our lives in much the same way as legal codes can.

I also learned that one of the big surprises I had at my local polling place recently is due to Secretary Bowen. The average age of the people who donate their time to run the polls in California is — again according to Secretary Bowen — 77 years old. But last time I went to vote there was a young woman there. We talked to her a bit — she was a high school student. It turns out that Secretary Bowen has a program to encourage high school and college students to participate in making the voting process possible. It seems a giant step forward from how I grew up, which was simply taking the whole process for granted.

Hundreds of millions of people rely on the accuracy of voting machines and the polling process to form our government. New voting machines are being developed, moving from paper-based ballots to electronic voting.

How accurate are those digital voting machines? How unbiased? Do they count every vote? Do they count every vote accurately and completely? How do they work? How tamper-proof are they? Is there a way to audit results? How good is the audit process? How would we know?

Right now it’s hard to tell. It turns out that how digital voting machines work is a secret. Voters are not allowed to know, to see or to test those machines or how they work. (I’ll speak of California here, as a result of talking to the California Secretary of State, but this is only an example of the problem.) We’re asked to “trust.”

The OSDV Foundation exists to change this. OSDV is a non-profit organization building open source voting machinery. This is important for several reasons:

• This allows voters to verify what our voting machines are doing. Like other open source projects, those of us with enough technical expertise can serve as consumer advocates and validate that our voting machines operate as they should.
• In voting, 1 or 2 percent is a giant amount. Many elections — at least in the US where I’m most familiar — are very, very close. A 1% to 2% margin of error may be acceptable in many business settings, but it is not acceptable in a critical election where it can change results. With open source products we can see and test and improve the quality, rather than simply trust that all is well.
• Casting and counting votes should not be a for-profit enterprise; it is the foundation of elected governments.
• Proprietary ownership of the means of voting IS a conflict of interest. According to the OSDV Foundation, right now something like 88% of the US voting infrastructure is owned by two companies, which will soon be one company.
• Good open source alternatives are likely to cause an improvement in the quality of the dominant (close to 90% market share) product offering.

OSDV is just reaching the point where its first products are just about ready for use. Having a viable alternative in the market is critical. Having a viable alternative that is open source and public-benefit is even better. OSDV is building a system that citizens can actually verify — a system we trust based on that ability to verify what is actually happening.

You can find out more about OSDV Foundation’s Trust the Vote project at trustthevote.org/background

Mitch Kapor recently announced the end of his involvement with the Open Source Applications Foundation and the Chandler project. Included in his comments is the brief note that:

OSAF also served as the fiscal sponsor for the Mozilla Foundation between its spinout from AOL/Netscape and when it secured its own tax-exempt non-profit status. In that respect, it played a small but important role in the great Firefox success story.

This is absolutely true but dramatically understates Mitch’s and OSAF’s role in helping Mozilla. Mitch began assisting Mozilla in late 2002. This was long before discussion with AOL about the the Mozilla Foundation began. 2002 was not the best of times for Mozilla. There was no Firefox. Our product was the Mozilla Application Suite. It was a good product, released in mid 2002. It far exceeded what anyone had expected us to produce and I remain proud of it to this day. But it wasn’t a well-adopted product. It wasn’t glamourous; it wasn’t elegant. It wasn’t the product that would spread like wildfire.

Mitch didn’t help Mozilla to join the bandwagon of something exciting. Mitch helped us because he knew that open source applications are important, and he knew that the browser’s place in an open source ecosystem is critical. I suspect we appeared more like an “ugly duckling” than anything exciting. But Mitch has a good eye for recognizing important things and he stepped up to help us.

I was working on Mozilla as a volunteer at the time, and had been doing so for about a year. I had been laid off from Netscape in early September of 2001. (I actually met Mitch face-to-face for the first time the day I was laid off from AOL. The meeting with Mitch was, as far as I can remember, the only thing that I did after I received the lay-off notice and before I left the building. At the time I knew it was interesting to meet Mitch, but I had no idea what that meeting would set in motion.) In late 2002 Mitch and I talked about me working at OSAF. I said I only wanted to work part-time because I wanted to keep volunteering with Mozilla. Mitch not only agreed, OSAF agreed to subsidize something like a day of week of my time for Mozilla.

Mitch and OSAF’s support of Mozilla grew from there. When the chance came to form the Mozilla Foundation Mitch’s assistance was invaluable. There was financial assistance. There was also Mitch’s personal involvement in helping the Mozilla Foundation get started and strengthening my courage to be responsible for the welfare of our initial employees and the fund-raising we expected to need. (Remember, at that time there was no Firefox, no Google, very little interest in the then-obscure piece of software known as the browser, and no obvious sources of funds.) A number of people thought we should take the $2MM pledge from AOL, hire 2 or 3 people to keep the machines running, and try to last as long as possible. Brendan and I knew more was required but it was a lot to take on. Mitch brought a level of sophistication and assistance that made a big difference in our ability to lay the foundations of the organization we know today. His assistance to me personally was enormous.

The Mozilla Foundation would have come into existence in some form without Mitch — an astonishingly dedicated and talented group of people were determined to see this happen. But it would not have started life anywhere near as strong without Mitch. Even with Mitch’s help, my role in building and funding the Mozilla Foundation was almost more than I could manage. Mitch’s involvement made a big difference. Mitch remains a member of the Mozilla Foundation Board of Directors and I continue to value his input enormously.

Good tools are a developer’s dream. I’ve been hearing the lament for better open source tools for open technology stacks ever since I started working with Mozilla. Today ActiveState is announcing the Open Komodo Project, bringing new open source tools for web developers into the Mozilla world.

ActiveState has been a participant in the Mozilla project for many years. Its award-winning Komodo IDE is build on Mozilla technology. ActiveState has been continuously building non-browser applications based on the Mozilla platform longer than almost anyone.

One of the goals of the Mozilla project is to create a world in which commercial organizations can and do make rational business decisions to promote open software and the open web. Today ActiveState takes another step on that path. And web developers have the promise of better open source tools to make their work easier. That makes today a good day indeed.

The Andrew Mellon Foundation sponsors awards of $50,000 and $100,000 for “not-for-profit organizations for leadership in the collaborative development of open source software tools with particular application to higher education and not-for-profit activities.”

The deadline for this year’s applications is April 16th. The requirements for these awards are rather specific. The core requirements are below; more details on the requirements can be found here.

If you think you or any organization(s) you know of meet these criteria, and could make use of the grant, please visit the Mellon award site or contact: Christopher J. Mackie at cjm@mellon.org (for full disclosure, I am a member of the Awards Committee).

The overview of criteria for these awards is that the organization “must have contributed its own financial and human resources to a software development project which meets all of the following criteria:

1. Is in public release (not just development) as an open source project, with source code actually available.

2. Provides a direct and demonstrably significant benefit to one or more of the Andrew W. Mellon Foundation’s traditional constituencies. These constituencies are: higher education, with a special emphasis on the arts and humanities; libraries and scholarly communications; performing arts; conservation and the environment; or museums and art conservation.

3. Meets the Foundation’s strict standards for excellence.

4. Includes the development of intellectual property that is freely available to the academic community under one of the approved open source licenses.”

The Mozilla project has always been a pioneer in bringing new functions and roles into an open source project. In the early days, this was integrating open source DNA with commercial organizations. A number of people are doing this day, and we’re still learning new things ourselves. Another topic in our world today is the additional of people in non-engineering roles. We’ve generally had a small amount of non-engineering personnel — though for many years this meant me. When the Foundation was formed Bart Decrem joined as our second non-technical person. About the time Bart left Chris Beard joined and picked up a range of non-technical topics. Today we have more such people. This includes roles such as:

• product-wide coordination (this role is often known as “product management” but I’m wary of this label because anything with the word “management” in it generates all sorts of reactions),
• communications and outreach (some of which is generally known as “marketing”, some of which is quite new like the Spread Firefox work),
• working with other organizations in the industry who want to build on our work (classic “Business Development” and “Partner Relations”).

This raises many interesting questions. One is that the open source community is not nearly as rich in home grown expertise in non-engineering areas as it is in developers. So filling these roles often means bringing in people who haven’t “come up through the project.” These folks who are new to the Mozilla project need to be accepted by the development community in order to be effective. Status as a Mozilla Corporation employee isn’t enough.

Another issue is that we don’t have an established path to meritocracy for non-technical roles. For potential developers, we know about several paths for getting involved and developing legitimacy — we know about the Quality Assurance path, we know about fixing bugs, we know something about hacking on the code, we know about writing a great extension and so on. We also have clear ways of identifying a person’s known expertise — they may be a peer for code, a “module owner” for code, etc. All of these are reasonably well understood roles within the project that convey a person’s expertise.

We don’t have analogous paths for non-engineering roles. We don’t yet have ways for the non-engineering staff to indicate the scope of expertise of their colleagues. And we are just building a core group of product coordination, community and partner relations (aka product management, product marketing, marketing, business development) contributors whose judgment and commitment to the project are understood by the technical teams to equal their own.

Itegrating non-engineering contributors takes a lot of trust and feeling our way gently. Those people joining us in non-engineering roles must trust that the technical contributors will give them a fair chance to participate, add value, become respected and gain influence and leadership. The engineering community must trust that these people who may be new to the Mozilla community and don’t have deep technical expertise are worth listening to and giving a fair shake.

Periodically I say or write something like “Please give this person the benefit of the doubt. If they seem off on a path that feels really wrong to you, please say so gently. Assume they are unaware of some relevant fact. Assume they are trying to do the right thing. Don’t assume they are evil, or out to change the project or claim control.” It’s generally worked so far, but it reflects the newness of these sorts of positions to our project (and I think, open source projects in general).

Relying on trust is a funny thing. One absolutely needs it. A well-known system for gaining respect and influence doesn’t mean much if participants don’t trust each other. And, who wants to work in a world that’s full of mistrust? But relying on trust alone without any guidelines is difficult in the long run, is intensely personal and leads to people needing to “reinvent the wheel.”

I’m interested to hear what other projects do, and if there is any general learning on this subject. In any case, we’re working through these issues now. No doubt both our successes and our missteps will be apparent 🙂

While at the Open Source convention I spent a bit of time introducing Joi Ito to a set of Mozilla and non-Mozilla open source people. Joi joined the board of the Mozilla Foundation recently, and OSCON was a great chance to introduce him to as many people as possible. One discussion was Joi, Allison Randal, Zak Greant, Cliff Schmidt and me. Allision, Cliff and Zak described their roles in the open source world, a focus on working towards consensus, on taking the pulse of the community, of keeping it healthy and an approach to problem solving. Zak outdoes us all with his organization, having found ways to track all sorts of non-coding issues in bug-tracking systems. But aside from this, we found a remarkable similarity in what the four of us think about.

For a moment it was odd, each person saying something like “I do a lot of what Allison does” or “My work sounds a lot like Zak’s.” At first it made it seem like there was nothing very special about the work. Then we realized that the O’Reilly gatherings are one of the few places where one could find enough people with this experience to make it seem mundane rather than highly unusual. Then we had a blast. It is actually a relief to find out that other people are doing similar things, finding the same problems, and trying out new things. There is a sense of adventure in having a role that is new enough that we figure it out as we go along. It’s also very helpful to have a few other people out there solving similar problems. It helps me know that I while I’m figuring things out (or “making them up”) I’m at least heading in the same direction as those I respect.

So, for example, what does it take to guide a foundation, as Allison does? Well, it takes a sense of people, and good intuition for what sorts of seemingly simple topics are likely to generate giant tensions if not handled delicately. It takes knowing when to let an issue fade away and when to make sure it is completely resolved. It takes an ability to find a common ground, and enough presence (or trust, or reputation, or *something*) to get people to consider that common ground. It turns out the rest of us either have, or wish we had, the set of skills to do exactly these things. I don’t see these as the main requirements in job descriptions or the main skillset on resumes, but each of us finds them to be fundamental to what we do. This isn’t unique to open source of course, but the use of these skills in an open source setting is pretty specialized.

I think it’s fair to say that none of us set out with this role in mind. Zak started coding (and is still the maintainer for part of that work), Allison started as a programmer (and is still the project manager for the Perl 6 project), and Cliff and I also have rather eclectic paths to our current roles. Maybe we’re self-selected to stepping in, thinking about organization and making things up when the need arises. Maybe none of us cares if others think what we’re doing is a dead-end path. Certainly moving to mozilla.org in 1999 did not look promising as a “career path.” (For those that don’t remember, 1999 and 2000 were the years when everyone proclaimed the Mozilla project a failure.) In any case, I’m interested in the questions of how open source projects self-organize and how they relate to other groups. Increasingly other creative people are thinking about this too. It’s a great time to be part of open source.

Here’s another aspect of the “organizational interface” I’d love to see enter the discussion: “What is different about working in open source projects? How much of what is different is attributable simply to the fact that bad management practices aren’t tolerated by volunteers?” Over and over again I hear people say “That’s because it’s an open source project” or “we can’t do that because it’s open source.” Sometimes these comments make sense to me.

But often when I hear this type of comment I think something like: “The course of action you are proposing won’t be liked by anyone, either volunteers or employees. If getting and keeping people motivated and producing above the call of duty is important to success, then you won’t do this sort of thing. Or at least not very often. Or if it’s really necessary, you’ll do a lot of explaining and trying to build consensus, and perhaps change some of your goals.”

Many of things that drive away volunteers (bad practices, lack of focus, bad organization) also drive employees away. It may take longer with employees, for a variety of reasons. Maybe the employees need time to find another way to support themselves before they leave. Maybe employment status has enough other benefits that on balance it’s worth it. But even if they stay, management practices that would drive volunteers away often result in dysfunctional organizations. The employees stay, but are at odds with their employer, and /or lose their commitment to the project.

On the other hand, there certainly are real differences, and open source practices such as transparency, peer review, and leadership based on reputation with one’s peers create a different dynamic. I’d like to see they dynamic better understood and adopted. I’d also like to learn its limitations through a more rigorous analysis than the current “Oh, that’s open source” meme.

Some time ago I wrote about being the “odd one out” at O’Reilly open source gatherings. Reading this makes me think of the saying “the more things change, the more they stay the same.” It’s obvious what’s changed. Mozilla Firefox has accomplished what no one thought was possible, and is the browser of choice for tens of millions of people worldwide. Mozilla Thunderbird provides an award-winning cross platform email client. I personally am known by a bunch of people in the Open Source world, and have been around longer than many (though certainly not all). The value of non-coding contributions is much more generally acknowledged, and I no longer wonder if people wonder if I’m making a contribution.

What hasn’t changed is a feeling of being on the fringes of the actual content of OSCON. This was a bit surprising, as OSCON now typically has “business” or “other” tracks besides the purely technical. So I was surprised to realize that few of them address the big topics on my mind. (I was however fascinated by the talks that Nat finds that are outside the core of open source — the Howtoons talk, the Origami talk, the BioBricks talk. These are all exciting and I’m grateful that the O’Reilly folks work to find them and introduce us to these new ideas. )

It’s not surprising that the programming part of the program isn’t my focus since I’m not doing any programming. But the open source gatherings now include an array of people who aren’t programmers and are thinking about other aspects of open source. A lot of this relates to open source adoption in the enterprise, a lot to commercial entities building on top of open source. Some relates to open source business models. Some always relates to licensing and IP issues; some addresses community building. This time I realized that none of these discussions address the core of what I’m thinking about. So that lead me to wonder: how would I describe the substantive discussions that would be fo most interest to me?

I’d like a series of discussions on the interface between open source projects and commercial organizations. There are many aspects to this interface. These include:

• Scope of people paid by the project: Apache small to zero; Mozilla significant
• Distribution of open source offerings by commercial entities: Positive effects; side effects.
• Companies paying people to contribute: Work directed by employer; by employee
• Working with commercial project and product management
• Generating funds: Necessary to support employees; risk that funds compromise decision-making or otherwise alienate the community
• Enterprise focused offerings build on / with open source: SpikeSource and SourceLabs
• Enterprise adoption: what it means from the project point of view
• Consumer adoption: what it means from the project point of view
• Inclusion of non-open source elements in a project distribution: always bad, or sometimes justifiable? (Mozilla has shipped the talkback module for many years)
• Commercial interests and multi-project interaction: OSDL, SpikeSource, SourceLabs, OSI license proliferation efforts
• Trademark considerations

These strike me as new discussion areas. We’re getting an increasing amount of information from enterprises about what’s involved in adopting open source software, and various compendiums of best practices are being developed. This is important information to understand.