Slashdot Mirror

The Mozilla Foundation which owns the Corp has funded several projects in 2007.

• Support and maintenance of the mozdev.org
• Development of Perl 6 and Parrot
• Implementation of accessibility features in the Dojo AJAX toolkit
• Enhancement of the NVDA open source screen reader for Windows
• Enhancements to the OpenSSL cryptographic library and Apache mod_ssl SSL/TLS module
• Enhance the Orca open source screen reader for Linux to support Firefox
• much more read the "projects in 2007" link...

Current work includes improving l10n tools Community Giving and Tools for the L10n Process

2006 10k USD to openbsd to continue development of openbsd and openssh. Mozilla Foundation activities, week ending 2006/03/31

The Mozilla Foundation which owns the Corp has funded several projects in 2007.

• Support and maintenance of the mozdev.org
• Development of Perl 6 and Parrot
• Implementation of accessibility features in the Dojo AJAX toolkit
• Enhancement of the NVDA open source screen reader for Windows
• Enhancements to the OpenSSL cryptographic library and Apache mod_ssl SSL/TLS module
• Enhance the Orca open source screen reader for Linux to support Firefox
• much more read the "projects in 2007" link...

Current work includes improving l10n tools Community Giving and Tools for the L10n Process

2006 10k USD to openbsd to continue development of openbsd and openssh. Mozilla Foundation activities, week ending 2006/03/31

Basically, by law non-profits are restricted in the kind of activities they can perform, particularly in generating revenue. Every time Mozilla wanted to work on some project with a corporation (like the arrangements with their default search engines or the creation of customized partner builds for eBay and others), they had to consult lawyers to find out if it was legal. By performing most of their activities under a corporation, all this legal uncertainty, expense, and restrictions could be avoided. The downside to this was that they had to start paying taxes, but that can be considered a good thing in that it supports society.

IANAL, but I don't think it's much different than how a university might own an endowment, which consists of stock in various for-profit corporations. What makes something a non-profit is not what it owns but what it uses its assets for (generating revenue vs. furthering some public good).

The key part of Mozilla's arrangement is that the Foundation is the sole shareholder of the Corporation; the employees don't get any shares to sell off in some kind of IPO (though they'd make a ton of money doing so). This allows it to generate revenue easily through the Corporation, but requires that this revenue must then be used for non-profit purposes (i.e. supporting the project and the internet). The whole thing is kind of an "organizational hack", but it works.

I haven't personally observed any real changes in their overall mission since this change; it was mostly a change on paper. The increase in revenue, though, has been very fruitful to the project. They started with just 10 employees; now they're past 100. They have a whole QA team and are creating several automated test frameworks and test suites (much of the code had gone without tests since the start of the Mozilla project). The whole build and release process is being automated, resulted in much faster releases of security fixes. And so on.

See this blog post by Mitchell Baker and this official FAQ on the reorganization for more details.

Oh, and they just came out with their 2007 grant figures for those interested.

Revenues: $66,840,850
Expenses: $19,776,193

"Profit" (or, change in net assets, since it's a non-profit): $27,893,735

According to Mitchell Baker (Mozilla CEO), salaries accounted for 70% of their expenses in 2006, so that's around $14 million. Net assets increased "only" by around $22 million (lower than the $28 million you calculated, perhaps because the Mozilla Corporation has to pay taxes).

Damn, it's good to be free. You'd think that the foundation would donate its money to fund other OSS projects, but as software people have discovered, the first priority of a foundation is to ensure the existence (and a lucrative existence at that) of its staff.

According to the numbers above, Mozilla employees could raise their salaries to 250% of what they now receive and still break even, but they chose not to. They could have made way more money by selling shares in the Mozilla Corp., instead of having it be fully owned by the non-profit Mozilla Foundation, but they didn't.

See this summary of Mozilla grants for 2006. Near the end:

It's too early to tell how much we'll spend in total, but I suspect we'll easily double the amount spent in 2006. As we move into 2008 we'll also be funding projects in more areas.

I get the impression they've gone slow at first to "test the waters" and find the best way to spend their money. They're even looking for help in giving away more:

The other constant is the importance of having people who can help us put together a funding program in particular areas, as Aaron Leventhal has done for Mozilla accessibility. To repeat what I wrote last year:

We're looking for more people like Aaron to whom we can successfully delegate responsibility for suggesting and overseeing grants in their area(s) of expertise. If you're one of those people I'm interested in hearing from you.

They've been funding lots of accessibility work, whereas many for-profits ignore disabled users entirely. They've sponsored conferences on using the internet for the public good. They also sponsor projects that are not part of FF and its revenue stream: work on Linux desktop accessibility, Creative Commons and the Participatory Culture Foundation, buying commercial javascript code and releasing it as open source, Apache and OpenSSL, and just now Perl 6.

Mozilla is working right alongside Opera, Apple, and others to advance web standards in the WHATWG and W3C. Mozilla funds work on web standards (test cases, conformance checkers, etc.), works hard to implement these standards, and even tries to bring useful features of their own platform (such as XBL and the XUL box model) into web standards so the whole web can benefit--even if it means diminishing any comparative advantage of FF over other browsers. Mozilla is working to keep the web platform viable and open in light of competition from Silverlight, Apollo, and others.

Having followed Mozilla very closely for the past several years, I can tell you that these people are not in it for the money; they are religiously devoted to the idea of advancing the Open Web for the pub

Revenues: $66,840,850
Expenses: $19,776,193

"Profit" (or, change in net assets, since it's a non-profit): $27,893,735

According to Mitchell Baker (Mozilla CEO), salaries accounted for 70% of their expenses in 2006, so that's around $14 million. Net assets increased "only" by around $22 million (lower than the $28 million you calculated, perhaps because the Mozilla Corporation has to pay taxes).

Damn, it's good to be free. You'd think that the foundation would donate its money to fund other OSS projects, but as software people have discovered, the first priority of a foundation is to ensure the existence (and a lucrative existence at that) of its staff.

According to the numbers above, Mozilla employees could raise their salaries to 250% of what they now receive and still break even, but they chose not to. They could have made way more money by selling shares in the Mozilla Corp., instead of having it be fully owned by the non-profit Mozilla Foundation, but they didn't.

See this summary of Mozilla grants for 2006. Near the end:

It's too early to tell how much we'll spend in total, but I suspect we'll easily double the amount spent in 2006. As we move into 2008 we'll also be funding projects in more areas.

I get the impression they've gone slow at first to "test the waters" and find the best way to spend their money. They're even looking for help in giving away more:

The other constant is the importance of having people who can help us put together a funding program in particular areas, as Aaron Leventhal has done for Mozilla accessibility. To repeat what I wrote last year:

We're looking for more people like Aaron to whom we can successfully delegate responsibility for suggesting and overseeing grants in their area(s) of expertise. If you're one of those people I'm interested in hearing from you.

They've been funding lots of accessibility work, whereas many for-profits ignore disabled users entirely. They've sponsored conferences on using the internet for the public good. They also sponsor projects that are not part of FF and its revenue stream: work on Linux desktop accessibility, Creative Commons and the Participatory Culture Foundation, buying commercial javascript code and releasing it as open source, Apache and OpenSSL, and just now Perl 6.

Mozilla is working right alongside Opera, Apple, and others to advance web standards in the WHATWG and W3C. Mozilla funds work on web standards (test cases, conformance checkers, etc.), works hard to implement these standards, and even tries to bring useful features of their own platform (such as XBL and the XUL box model) into web standards so the whole web can benefit--even if it means diminishing any comparative advantage of FF over other browsers. Mozilla is working to keep the web platform viable and open in light of competition from Silverlight, Apollo, and others.

Having followed Mozilla very closely for the past several years, I can tell you that these people are not in it for the money; they are religiously devoted to the idea of advancing the Open Web for the pub

Well, the description of your history is correct in that, that when Cacert wanted inclusion at Mozilla, all alarm bells came on...So far so good.

But the Mozilla CA policy exists in some form since beginning of 2005 at the web site of Frank Hecker (President of the Mozilla Foundation). That was about when StartCom started its own authority. Since then many CAs were included and processed at Mozilla (See history), based on that policy, the very same policy which was eventually approved my Mozilla.

Therefore what I meant is, that already for over two years, Cacert could have been included - the very same way StartCom was. More than that, the Mozilla policy was created and defined in a way, which made it possible for Cacert and StartCom to comply.

However, I think that there are some real problems with community projects in order to have them comply even to the most basic requirements of CAs. This is one of the reasons, why I personally don't believe in the current structure of Cacert to be ever successful - even if it's a nice idea.

Well, the description of your history is correct in that, that when Cacert wanted inclusion at Mozilla, all alarm bells came on...So far so good.

But the Mozilla CA policy exists in some form since beginning of 2005 at the web site of Frank Hecker (President of the Mozilla Foundation). That was about when StartCom started its own authority. Since then many CAs were included and processed at Mozilla (See history), based on that policy, the very same policy which was eventually approved my Mozilla.

Therefore what I meant is, that already for over two years, Cacert could have been included - the very same way StartCom was. More than that, the Mozilla policy was created and defined in a way, which made it possible for Cacert and StartCom to comply.

However, I think that there are some real problems with community projects in order to have them comply even to the most basic requirements of CAs. This is one of the reasons, why I personally don't believe in the current structure of Cacert to be ever successful - even if it's a nice idea.

The /. summary is pretty worthless (is anyone surprised?). This is only related to Flash inasmuch as Flash has a JavaScript VM / JIT Compiler, and that technology has been released to Mozilla so that they can take advantage of those performance improvements. At least that's how I read the news from people actually involved.

Brendan Eich's blog
Frank Hecker's blog

From Frank Hecker, executive director of the Mozilla Foundation, at http://www.hecker.org/mozilla/adobe-mozilla-and-ta marin:

The current SpiderMonkey JavaScript engine (used in Firefox, etc.) will not be replaced, as it does more than just provide a virtual machine; rather the Tamarin code will be integrated into SpiderMonkey. On compilers, the current SpiderMonkey engine can convert JavaScript to byte code, but does not have the ability to convert byte code to native machine instructions; this is a major feature that Tamarin provides. I don't know enough to comment on relative code quality; I'll leave this to others who've actually had experience with both code bases.

..on the issue by Mozilla Foundation's executive director: Frank Hecker's blog

See this blog post from about a year ago on this topic.

OpenBSD project. The Mozilla Foundation made a $10K donation to the OpenBSD project in support of development of OpenBSD, OpenSSH, and related activities. The OpenBSD project does great work in the area of creating a secure Unix-like operating system (which runs Firefox, of course) and developing related security technologies. In particular the Mozilla project uses SSH extensively for various purposes, including securing connections to the Mozilla CVS repository. The OpenBSD and OpenSSH projects have been experiencing some financial difficulties, and based on their importance to the Mozilla project and to the wider open source and free software world we felt that it was well worth showing our support for them.

According to the source linked to in the actual article, it's to OpenBSD.

Even better, follow the link. It turns out that ALL the main browser people, MS, Mozilla, Opera and KDE got together and agreeded on colours and padlock information and layout for the address bars. It won't just be MS colouring the bar in IE7, everyone will, and in a common, standard way.

So if every browser is going to do it, in the same way, then how come only MS is being dismissed here?

Setting Up Shop by Frank Hecker is an excellent intro to various Open Source business models

I beleve the LGPL (or maybe even stright GPL) works, as long as you don't mind shipping source to all your "binary customers" (or shipping it on request). Of corse it won't prevent other people from doing the same thing, but Red Hat seems to be making enough money even with SuSE, Caldera, Slackware, et. al. in the ring.

However I think you may want to look at the MPL (Mozilla Public Licence) as well. It has a few advantages to people who want a shrinkwrap and free reslease:

• If someone modifys your MPLed source to use a Patented algo, they also assign the rights to use the patent (for at least the MPLed program) to anyone else who has the MPLed program. I assume this only works if they have the right to assign rights (i.e. if Lucent added an XOR cursor to Mozilla the right would assign, but if I did it, it wouldn't assign because I don't hold a patent on XOR cursors, Lucent does). This is applicable even to software where you are not intrested in doing a shrinkwrap release. It is a large part of why I picked it for w3juke.
• You (the original author) are granted the special right to make your own modifications to the code without releasing them. In the long run it will be simpler to release them and get the benifit of more coders debugging, but it might be helpful to add a few features to a shrinkwrap version and fold them into the real release later (something like what Aladin does with Ghostscript).
• It is far better to use a licence people accept as Open Source allready (after all people accept Mozilla as OSS, even if there is debate on how successful it has been). If you end up with the LGPL or BSDL and need to add/change it a little then you could be in for a bumpy ride, both in getting it accepted, and later in finding out if it does what you want if it gets chalanged.

You might want to look at The Open Source website, expecally their short approved licences list.

Lastly I think you might want to look at Setting Up Shop: The Business of Open-Source Software which has a discussion of some of hte licences, and some bisness models to make money useing them (I havn't read this yet, just skimed it, so I appolgise if it isn't as good as I hope).

Forgot to say who did that (very nice) analysis.

It was Frank Hecker...

Cheers,
Ben

heckers paper which convinced the management is in here. the whole story is here.

the event was important in the history of open source, as it was the first major company opening it's source and many followed by now ( opencascade.org, zope.org )

When you see a book written by "A with B" it usually means that A didn't write a word: A was interviewed by B, and then B wrote it.

For example, the Freeing the Source: The Story of Mozilla chapter of O'Reilly's Open Sources book is credited as ``by Jim Hamerly and Tom Paquin with Susan Walton.'' In fact, that document was written entirely by Susan Walton (and I think she did a good job of it.) She based it on extensive interviews with Hammerly, Paquin, and myself. I pissed off a lot of people (at Netscape and O'Reilly) by refusing to allow them to list me as an author, because, quite simply, I hadn't written a word of it, and I didn't want to take credit for something I didn't write.

``This is how the publishing industry works,'' they told me. ``Everyone knows what `with' really means.'' Well, I hadn't known that, and I found it to be deceptive, so I wouldn't play along. I thought it should have been credited as ``by Susan Walton based on interviews with ...'' or ``...as told to...'' or something, but they hated those.

Anyway, about the Red Hat book...

I thought the history of Red Hat was interesting. But I'll comment on the parts I have direct knowlege of:

The inside-Netscape history is fairly accurate, including the deliberations about the licenses, but as far as I can tell most of it is lifted directly from Frank Hecker's writings on the subject. If you're interested in this part, you should read Hecker's papers, because they are a much better explanation in their pre-condensed form.

I thought their summary of why we didn't use GPL left out a very important detail. Anyone who understands copyright law would respond to the reasons they gave (``we want to bundle with other proprietary software'') by pointing out that the copyright holder always has the right to do things like that. The important point that they failed to mention is that if the copyright holder does so, they eliminate their ability to take contributions from the outside, which is pretty much a deal-breaker. They mentioned that we had a very hard time trying to find a solution to our various license-related problems, but I don't think they did a very good job of explaining what those problems were, or why we reached the decisions we did. Maybe this wasn't an important detail to a book about Red Hat, but if not, they shouldn't have included it at all. What they did include is fairly muddled.

Throughout the book, there were quite a few things that jumped out at me, like saying in one paragraph about Cryptozilla on page 98 ``less than a month after the source code was released ... the group added full encryption,'' and then saying two paragraphs later, ``fifteen hours after the source code release, a fully crypto-enabled version of Mozilla for Linux was released.''

So yeah, 15 hours is less than a month. But the book contains a lot of strange errors like this. It's as if there were no review copies distributed at all. (Were there?)

The entirety of the first year of mozilla.org, between April 1998 and April 1999, seems to be skipped over somewhere in the middle of page 100. Then they say, ``it took over a year for Netscape to ship Netscape Navigator version 5.0.''

When did they ship that exactly? For those keeping score at home, it has now been 18 months, and will certainly have been two years, if it ships at all.

Also they consistently misspelled my name (for which Bob was extremely apologetic -- he mailed me about it a few days before the book was released.) Not that I particularly care about trivia like the spelling of my name, but getting that wrong in a book is really a rookie move, and reflects badly on the book that something so basic slipped through.

I think that all of these problems stem from sloppy editing and lack of review. This book would have been much better if they had taken another month or two to distribute review copies and get feedback and corrections.

``Release early, release often'' doesn't work so well with physical media.