Posts Tagged with “open source”

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