I can't speak for Mitchell, but I presume that when she wrote about "not pursuing a profit" she was referring to the fact that the goal of traditional "for profit" corporations is to pursue profits in order to maximise the financial value for shareholders (private or public). That is not the case for the Mozilla Corporation; its charter is not to maximize shareholder value but rather to advance the mission of the Mozilla Foundation.
There's an open source angle to FIPS 140-x that's worth mentioning: The
Network Security Services open source crypto implementation embedded in Mozilla and Mozilla-based products has been FIPS 140-1 validated, as was the original proprietary Netscape Security Services code from which the current open source NSS was derived. The validation efforts were sponsored by Netscape originally and by Sun (iPlanet) for the open source version; for more information see the list of FIPS 140-1 validated products and look for certificates 247 and 248 (Sun) and 47 (Netscape).
As others have noted, FIPS 140-x validation is not a panacea; however it does add some additional (and IMO useful) product review beyond what you'd get with standard internal QA plus public review (for open source crypto products). I think it would be great if some vendor or vendors stepped up and sponsored FIPS 140-x validation for OpenSSL and other popular open source crypto implementations.
Does this mean that each branch will have progressively different bug fixes and feature sets?
Yes. The 1.0.x series of releases will contain bug fixes, but no new features. The 1.1, 1.2, etc., series of releases will contain both bug fixes and new features. In addition, there may be some bug fixes made to the 1.1, 1.2, etc., releases that are not made to the 1.0.1, 1.0.2, etc., releases, because the risk of fixing the bug is too high (that is, fixing a particular bug might cause multiple other bugs to appear).
Will we eventually have to choose from two different mozillas?
Yes, in the sense that you can decide either to install the 1.0.1, 1.0.2, etc., releases, or you can decide to install the 1.1, 1.2, etc., releases. However I expect most Mozilla users to install 1.1, 1.2, etc. The 1.0.1, 1.0.2, etc., releases are for people who don't care about the new features but instead want a stable version that doesn't change much from release to release; for example, a company building a Mozilla-based product may be interested in this.
Does this mean that each branch will have progressively different bug fixes and feature sets?
Yes. The 1.0.x series of releases will contain bug fixes, but no new features. The 1.1, 1.2, etc., series of releases will contain both bug fixes and new features. In addition, there may be some bug fixes made to the 1.1, 1.2, etc., releases that are not made to the 1.0.1, 1.0.2, etc., releases, because the risk of fixing the bug is too high (that is, fixing a particular bug might cause multiple other bugs to appear).
Will we eventually have to choose from two different mozillas?
Yes, in the sense that you can decide either to install the 1.0.1, 1.0.2, etc., releases, or you can decide to install the 1.1, 1.2, etc., releases. However I expect most Mozilla users to install 1.1, 1.2, etc. The 1.0.1, 1.0.2, etc., releases are for people who don't care about the new features but instead want a stable version that doesn't change much from release to release; for example, a company building a Mozilla-based product may be interested in this.
JMS is the Java Message Service. ETX is a product from TIBCO; there's also a TIBCO product called Rendezvous, and I presume that's what the original poster meant by "RV". "UDB" is "Universal Database", used in connection with IBM's DB2 database product in its various incarnations.
openadaptor BOF at LinuxWorld in New York
on
Open Source Banking
·
· Score: 2
Sorry, I forgot to mention: If you will be attending the LinuxWorld conference in New York City this week, there will be a Birds of a Feather session for openadaptor on Thursday, February 1, from 6-7:30 pm EST in room 1E11 of the Jacob Javits Convention Center. The openadaptor developers from Dresdner Kleinwort Wasserstein will be on hand to discuss the openadaptor technology in depth and answer any technical questions you might have. This event is open to all, so please feel free to drop by and attend if you're interested in learning more about openadaptor.
To clarify what the openadaptor software is and is not: As the original poster noted, the openadaptor software provides easy ways to set up connections between different types of applications; it is basically an integration toolkit. However the openadaptor software is not in and of itself a banking application. Thus, for example, openadaptor was used to help implement a global equities derivative trading system at Dresdner Kleinwort Wasserstein, but the openadaptor code itself does not perform the financial calculations involved in derivatives trading.
I should also note that the potential usefulness of openadaptor extends well beyond banking and financial services; any company with large complex IT systems might be interested in it, especially companies that have to integrate systems across divisional or corporate boundaries, for example as a result of a merger or acquisition. (This includes Dresdner Kleinwort Wasserstein itself -- it was known as Dresdner Kleinwort Benson until it recently merged with Wasserstein Perella.)
To address your main point: Under the US export regulations, persons in the US are allowed to put up open source crypto code for anonymous download on the Internet; they are not liable if the software "ends up in a country that the US doesn't like", as long as they didn't specifically and knowlingly send it to that country. (For example, US persons can't legally email crypto code to someone in Iraq.) Under the new US regulations there are no prohibitions against putting open source crypto code on a public Internet site and making public announcements about where to find it.
If you're in Ireland then there may be additional Irish laws and regulations that apply to you, but if you release the software as described above then I don't know of any problems due to US regulations.
Final point: You write "I then release the lot under the GPL, as required". Actually, if you use NSS code in your own code then you don't have to use the GPL if you don't want to. You could release your own code under the MPL, or under some other license compatible with the GPL or the MPL, for example an XFree86-style license.
I'm surprised no one's mentioned that you already can read SSL pages in Mozilla, by installing the Personal Security Manager.
Right, the PSM available for download from the iPlanet site is strictly speaking a proprietary product, because it includes a proprietary crypto library that was originally licensed from RSA Security. Future versions of PSM that will be available from the mozilla.org site will be nonproprietary open source software, because they will instead include the open source crypto library just released by the iPlanet developers.
No, NSS is based on the original SSL library that Netscape developed for Netscape Navigator 1.0 and subsquently enhanced through the years. NSS is independent of OpenSSL/SSLeay and (to my knowledge) doesn't have any code in common with it.
NSS is going to be included with Netscape 6 (as it was with Netscape COmmunicator 4.x), and Netscape (actually, iPlanet, the Sun/Netscape Alliance) donated the code for use with Mozilla as well; the iPlanet developers also created new code for the RSA algorithm and other crypto algorithms, to replace the code originally used, which was from the proprietary BSAFE crypto library created by RSA Security.
There's no reason in theory why OpenSSL couldn't be used with Mozilla as well, either as an alternative SSL implementation to NSS or just as a crypto library called by NSS; however no one has yet developed and released all the code necessary to make OpenSSL work with Mozilla. You should contact the OpenSSL developers for more information, as I don't have any special knowledge of what their plans are relating to Mozilla.
Now, just what does "minimal" mean, coz they're a bit short on detail?
My apologies for not expanding on what "minimal" means. I'll update the FAQ to clarify this. Basically the remaining restrictions have to do with people in the U.S. not being able to "knowingly" export crypto code to a few countries (Iran, Iraq, etc.), together with requirements for moizlla.org to notify the US Bureau of Export Administration and NSA when new crypto code gets posted to the mozilla.org site.
Again, I'll update the FAQ to include a more complete explanation.
MPL makes Netscape the privileged first-developer of all MPLed code...
No, no, no. The Mozilla Public License provides no special privileges to Netscape. You are thinking of the Netscape Public License (NPL), which does contain such provisions. The MPL was created specifically to have a Mozilla license that was generic and did not give Netscape special treatment.
Also note that as part of the effort to do dual licensing, the intent is to eliminate use of the NPL with Mozilla code; any code currently licensed under the NPL should end up dual licensed under the _MPL_ and GPL.
I believe that the MPL doesn't allow other companies to take the code and make it part of their own proprietary product.
This is incorrect. The MPL allows code to be combined with code under other licenses, including proprietary licenses. Netscape is using this provision to create a Mozilla-based product (Netscape 6) that includes proprietary functionality; however any other company could do the same thing if they wished. There are no "special privileges" for Netscape in the Mozilla Public License (as there were in the original Netscape Public License, from which the MPL was derived).
hy not just put it all under the GPL? Both licenses are equivalent.
The MPL and GPL are not equivalent. The most important difference is that the MPL explicitly permits MPLed code (e.g., Mozilla code) to be combined with code under other licenses, including (implicitly) proprietary licenses.
On the other hand, the GPL explicitly mandates that if code licensed under the GPL is combined with other code not under the GPL, then GPL terms and conditions must be complied with for the resulting derived work. This effectively prevents creating and distributing works combining GPLed code and code under proprietary licenses.
The MPL/GPL dual licensing scheme is intended to maximize the number of developers who can use Mozilla code in their own applications; the goal is to allow them to use the Mozilla code under MPL terms and conditions or under GPL terms and conditions, whichever is appropriate given the license terms being used on the developers' own code.
If you are intending to produce a component that can be used by other apps (either by putting it in a library or via CORBA), does that mean that the third party app must also be GPL/MPL ?
No,you can use a license of your choice, as long as the terms and conditions of your license are compatible with the terms and conditions of either the MPL or the GPL (or both). So, for example, if you want to use Mozilla code within a proprietary commercial application then you would use the Mozilla code under MPL terms and conditions; the MPL permits you to combine Mozilla code with code under a proprietary license to create a derived work. You simply have to comply with MPL terms and conditions for the Mozilla code you're using; the MPL does not affect the license terms you use for your own (non-Mozilla) code.
On the other hand, if you use Mozilla code within your application and your own code is licensed under the GPL, then you would choose to license the Mozilla code under the GPL (i.e., you would choose the other option under the dual-licensing scheme). In that case you (and people to whom you distribute the application) would have to comply with GPL terms and conditions for both your own code and the Mozilla code.
There's a lot of useful advice in prior posts, so I won't try and rehash it; I'll just add a few additional comments. I'm assuming that you're mainly interested in creating and sustaining an open source alternative to the current proprietary software you're using, and you don't have any larger business goals related to the software. I'm also assuming that a primary reason you want to convert to using open source software is to share development costs, etc., with others; thus sooner or later you'll have to get other people actually working with you on the open source development project.
You didn't say whether you planned to develop the software using only internal people and then release it, or whether you wanted to co-develop with some independent developers from the very beginning. This can make a big difference. If you develop everything internally and then release the software then you'll face the problem of interesting people in working on something that they didn't have any part in creating, and which appears on the surface to be a company-specific project of limited general interest. On the other hand, if you try and bring people in earlier on then you'll be in a situation where you won't have anything yet that runs and is usable.
If you develop the software totally in-house and then release it, this is to some degree comparable to projects like Mozilla. In the Mozilla project the original Netscape developers started out as the designated "module owners" responsible for particular portions of the code, and then as non-Netscape contributors came on board they first contributed patches that were checked in by others, then they could get check-in access themselves (with their code being reviewed by module owners or others) and then finally they had the opportunity to become module owners themselves for particular components. So except for people in your company everybody else starts out "on the outside looking in"; this is unavoidable under this model, and has the effect of stretching out the period before the project is seen as a true open public effort (mostly) independent of your company. (Again, Mozilla is the classic case of this.)
So there are some good reasons to try to get other people outside your company involved relatively early on. Then they can participate as code contributors and module owners for whatever part of the project interests them. As for exercising overall control, you can have a single person overseeing the project or you can try and do a committee-style structure like the Apache folks did.
(The Apache project is one of the most formal ones in terms of their internal organization, and it's probably worth you're checking out what they did with the Apache Software Foundation. Also check out Brian Behlendorf's chapter in the "Open Sources" book, particularly the "Bootstrapping" section, for some information on the types of people you'll need in the course of the project, either from your company or from somewhere else.)
If you want to get people involved early on then you'll need to find people who are motivated to participate at the design stage. You might try looking for existing open source projects that are related to the problem space that your planned software addresses; those projects might have existing software you can reuse, and even more important may have people interested in participating in your project starting at the ground floor. (Even if you develop the software internally you're going to want to do this sort of "market study" anyway, because there's no point in doing work and then finding out that someone else has created a project that duplicates yours and prevents your project attracting developers.)
Another option is actually contracting with independent developers to work on the project in the early development phases, either to supplement your own developers or even to totally outsource the work. (For example, this is what Galactic Marketing did with the open source workflow project they're doing.) Even if you contract work out there's nothing to stop you from running the project "in the open" so others can check it out and provide useful feedback (as indeed happened with the Galactic Marketing project); whether you host the project yourself or somewhere else, you want to have some level of public access so interested observers have an entry point into the project.
That's all the comments I have time for now; good luck with your project!
Okay, can someone with real knowledge of the situation brief Slashdot on what the heck is going on with Mozilla?
Well, I'm by no means an expert, but I'll try: M14 was a Mozilla milestone like other milestones, and there will be other milestone releases in the future: M15, M16, etc. After release of M14 and a few days of additional bug fixing, Netscape went onto a Mozilla branch in order to prepare for release of beta 1 of Netscape 6; Netscape will do more bug fixing on that branch, and will then combine the Mozilla code with Netscape-proprietary code (from what is known as the Netscape "commercial tree") to create the Netscape 6 beta 1 release.
Mozilla development and bug fixing continues on the trunk, with contributions from both Netscape developers and others, and is planned to result in an M15 milestone release sometime in April and an M16 milestone release sometime in May. As I understand it, Mozilla bug fixes made by Netscape on their beta 1 branch are being rolled back onto the trunk, and Netscape will use future Mozilla milestones as the basis for future Netscape 6 beta releases and then Netscape 6 production release. (Presumably they will work on branches as necessary to create those releases, just as they are doing now with beta 1.)
In a side issue, once M14 was released the security/crypto developers at iPlanet E-Commerce Solutions (the Sun-Netscape Alliance) used an M14-based branch to add and test changes to Mozilla needed to invoke SSL functionality provided by the separate Netscape Personal Security Manager binaries. As I understand it, those changes have now been rolled back onto the Mozilla trunk and will be in M15. (I think Netscape 6 beta 1 should have those SSL-related changes as well, since they were originally taken from the Netscape commercial tree.)
Actually, Debian allows software in their distribution as long as it conforms to the Debian Free Software Guidlines, which the MPL does.
Also, the Mozilla SSL implementation (in the Personal Security Manager and Network Services Services library) was released under both the MPL and GPL. This was done specifically to allow this code to be used in GPLed software. See the Mozilla Crypto FAQ.
Mozilla is no longer open source since now they are going ahead and including binary only stuff.
There is no binary-only code hosted on mozilla.org as part of the Mozilla project. The Netscape Personal Security Manager binaries (which provide SSL support for Mozilla) have been provided by iPlanet, because they have the license from RSA to include the necessary code and algorithms to build a complete binary executable ready for use (in this case under the "Netscape" brand).
All of the other code in PSM is or will be available in source form on the mozilla.org site. People who want to use that source code to build their own PSM binaries will be able to do so, as long as they have separate source code to implement the RSA-licensed parts.
For reference, there are three sets of relevant source code needed to provide SSL support for Mozilla:
Source code in Mozilla itself to call out to PSM. This is already on the M14 branch in complete form.
Source code in PSM and the underlying Network Security Services (NSS) library, where the SSL protocol is implemented. Most of this source code is already available on mozilla.org; the rest will be released after being cleaned up for public release.
Source code in the RSA-proprietary library to do the actual encryption operations. This source code will never be available on mozilla.org (not being open source), and will have to replaced with equivalent code from other sources.
Right, I'm familar with OpenSSL, and yes it is one possible source for implementations of the underlying crypto algorithms, including RSA. There are others as well. The PSM/NSS source code already released by iPlanet (formerly the Sun-Netscape Alliance) or to be released later already includes code for the SSL protocol itself, it needs the crypto code to go underneath SSL.
There are browsers that support SSL, but Mozilla is not yet one of them; anything that even smelt of crypto was ripped out of the original Mozilla code due to US export regulations. What's being added to Mozilla are hooks to allow invocation of a component to do SSL; at least one such module (PSM) will be made available in binary form and also has had partial source code released for it, with the goal of complete source down the road. People are free to implement other alternative SSL modules for Mozilla as well.
Mozilla does not yet have support for encrypted email, either S/MIME or PGP-based. I expect both to become available later sometime, but it's too soon to guess at dates.
Slashdot Mirror
I can't speak for Mitchell, but I presume that when she wrote about "not pursuing a profit" she was referring to the fact that the goal of traditional "for profit" corporations is to pursue profits in order to maximise the financial value for shareholders (private or public). That is not the case for the Mozilla Corporation; its charter is not to maximize shareholder value but rather to advance the mission of the Mozilla Foundation.
As others have noted, FIPS 140-x validation is not a panacea; however it does add some additional (and IMO useful) product review beyond what you'd get with standard internal QA plus public review (for open source crypto products). I think it would be great if some vendor or vendors stepped up and sponsored FIPS 140-x validation for OpenSSL and other popular open source crypto implementations.
From this article I get the impression that any Tom, Dick, or Harry can go out, 'perform testing' and give away FIPS certs for money.
This is not the case. FIPS 140-1/140-2 test labs must be approved by NIST through a formal accreditation program.
Does this mean that each branch will have progressively different bug fixes and feature sets?
Yes. The 1.0.x series of releases will contain bug fixes, but no new features. The 1.1, 1.2, etc., series of releases will contain both bug fixes and new features. In addition, there may be some bug fixes made to the 1.1, 1.2, etc., releases that are not made to the 1.0.1, 1.0.2, etc., releases, because the risk of fixing the bug is too high (that is, fixing a particular bug might cause multiple other bugs to appear).
Will we eventually have to choose from two different mozillas?
Yes, in the sense that you can decide either to install the 1.0.1, 1.0.2, etc., releases, or you can decide to install the 1.1, 1.2, etc., releases. However I expect most Mozilla users to install 1.1, 1.2, etc. The 1.0.1, 1.0.2, etc., releases are for people who don't care about the new features but instead want a stable version that doesn't change much from release to release; for example, a company building a Mozilla-based product may be interested in this.
Does this mean that each branch will have progressively different bug fixes and feature sets?
Yes. The 1.0.x series of releases will contain bug fixes, but no new features. The 1.1, 1.2, etc., series of releases will contain both bug fixes and new features. In addition, there may be some bug fixes made to the 1.1, 1.2, etc., releases that are not made to the 1.0.1, 1.0.2, etc., releases, because the risk of fixing the bug is too high (that is, fixing a particular bug might cause multiple other bugs to appear).
Will we eventually have to choose from two different mozillas?
Yes, in the sense that you can decide either to install the 1.0.1, 1.0.2, etc., releases, or you can decide to install the 1.1, 1.2, etc., releases. However I expect most Mozilla users to install 1.1, 1.2, etc. The 1.0.1, 1.0.2, etc., releases are for people who don't care about the new features but instead want a stable version that doesn't change much from release to release; for example, a company building a Mozilla-based product may be interested in this.
For information on accessibility support being developed for Mozilla, see the Mozilla accessibility project and the netscape.public.mozilla.accessibility newsgroup.
Nothing. There is no relationship between GameXchange and SourceXchange, except that the names are similar.
JMS is the Java Message Service. ETX is a product from TIBCO; there's also a TIBCO product called Rendezvous, and I presume that's what the original poster meant by "RV". "UDB" is "Universal Database", used in connection with IBM's DB2 database product in its various incarnations.
Sorry, I forgot to mention: If you will be attending the LinuxWorld conference in New York City this week, there will be a Birds of a Feather session for openadaptor on Thursday, February 1, from 6-7:30 pm EST in room 1E11 of the Jacob Javits Convention Center. The openadaptor developers from Dresdner Kleinwort Wasserstein will be on hand to discuss the openadaptor technology in depth and answer any technical questions you might have. This event is open to all, so please feel free to drop by and attend if you're interested in learning more about openadaptor.
To clarify what the openadaptor software is and is not: As the original poster noted, the openadaptor software provides easy ways to set up connections between different types of applications; it is basically an integration toolkit. However the openadaptor software is not in and of itself a banking application. Thus, for example, openadaptor was used to help implement a global equities derivative trading system at Dresdner Kleinwort Wasserstein, but the openadaptor code itself does not perform the financial calculations involved in derivatives trading.
I should also note that the potential usefulness of openadaptor extends well beyond banking and financial services; any company with large complex IT systems might be interested in it, especially companies that have to integrate systems across divisional or corporate boundaries, for example as a result of a merger or acquisition. (This includes Dresdner Kleinwort Wasserstein itself -- it was known as Dresdner Kleinwort Benson until it recently merged with Wasserstein Perella.)
If you're in Ireland then there may be additional Irish laws and regulations that apply to you, but if you release the software as described above then I don't know of any problems due to US regulations.
Final point: You write "I then release the lot under the GPL, as required". Actually, if you use NSS code in your own code then you don't have to use the GPL if you don't want to. You could release your own code under the MPL, or under some other license compatible with the GPL or the MPL, for example an XFree86-style license.
Right, the PSM available for download from the iPlanet site is strictly speaking a proprietary product, because it includes a proprietary crypto library that was originally licensed from RSA Security. Future versions of PSM that will be available from the mozilla.org site will be nonproprietary open source software, because they will instead include the open source crypto library just released by the iPlanet developers.
No, NSS is based on the original SSL library that Netscape developed for Netscape Navigator 1.0 and subsquently enhanced through the years. NSS is independent of OpenSSL/SSLeay and (to my knowledge) doesn't have any code in common with it.
NSS is going to be included with Netscape 6 (as it was with Netscape COmmunicator 4.x), and Netscape (actually, iPlanet, the Sun/Netscape Alliance) donated the code for use with Mozilla as well; the iPlanet developers also created new code for the RSA algorithm and other crypto algorithms, to replace the code originally used, which was from the proprietary BSAFE crypto library created by RSA Security.
There's no reason in theory why OpenSSL couldn't be used with Mozilla as well, either as an alternative SSL implementation to NSS or just as a crypto library called by NSS; however no one has yet developed and released all the code necessary to make OpenSSL work with Mozilla. You should contact the OpenSSL developers for more information, as I don't have any special knowledge of what their plans are relating to Mozilla.
My apologies for not expanding on what "minimal" means. I'll update the FAQ to clarify this. Basically the remaining restrictions have to do with people in the U.S. not being able to "knowingly" export crypto code to a few countries (Iran, Iraq, etc.), together with requirements for moizlla.org to notify the US Bureau of Export Administration and NSA when new crypto code gets posted to the mozilla.org site.
Again, I'll update the FAQ to include a more complete explanation.
No, no, no. The Mozilla Public License provides no special privileges to Netscape. You are thinking of the Netscape Public License (NPL), which does contain such provisions. The MPL was created specifically to have a Mozilla license that was generic and did not give Netscape special treatment.
Also note that as part of the effort to do dual licensing, the intent is to eliminate use of the NPL with Mozilla code; any code currently licensed under the NPL should end up dual licensed under the _MPL_ and GPL.
This is incorrect. The MPL allows code to be combined with code under other licenses, including proprietary licenses. Netscape is using this provision to create a Mozilla-based product (Netscape 6) that includes proprietary functionality; however any other company could do the same thing if they wished. There are no "special privileges" for Netscape in the Mozilla Public License (as there were in the original Netscape Public License, from which the MPL was derived).
The MPL and GPL are not equivalent. The most important difference is that the MPL explicitly permits MPLed code (e.g., Mozilla code) to be combined with code under other licenses, including (implicitly) proprietary licenses.
On the other hand, the GPL explicitly mandates that if code licensed under the GPL is combined with other code not under the GPL, then GPL terms and conditions must be complied with for the resulting derived work. This effectively prevents creating and distributing works combining GPLed code and code under proprietary licenses.
The MPL/GPL dual licensing scheme is intended to maximize the number of developers who can use Mozilla code in their own applications; the goal is to allow them to use the Mozilla code under MPL terms and conditions or under GPL terms and conditions, whichever is appropriate given the license terms being used on the developers' own code.
If you are intending to produce a component that can be used by other apps (either by putting it in a library or via CORBA), does that mean that the third party app must also be GPL/MPL ?
No,you can use a license of your choice, as long as the terms and conditions of your license are compatible with the terms and conditions of either the MPL or the GPL (or both). So, for example, if you want to use Mozilla code within a proprietary commercial application then you would use the Mozilla code under MPL terms and conditions; the MPL permits you to combine Mozilla code with code under a proprietary license to create a derived work. You simply have to comply with MPL terms and conditions for the Mozilla code you're using; the MPL does not affect the license terms you use for your own (non-Mozilla) code.
On the other hand, if you use Mozilla code within your application and your own code is licensed under the GPL, then you would choose to license the Mozilla code under the GPL (i.e., you would choose the other option under the dual-licensing scheme). In that case you (and people to whom you distribute the application) would have to comply with GPL terms and conditions for both your own code and the Mozilla code.
You didn't say whether you planned to develop the software using only internal people and then release it, or whether you wanted to co-develop with some independent developers from the very beginning. This can make a big difference. If you develop everything internally and then release the software then you'll face the problem of interesting people in working on something that they didn't have any part in creating, and which appears on the surface to be a company-specific project of limited general interest. On the other hand, if you try and bring people in earlier on then you'll be in a situation where you won't have anything yet that runs and is usable.
If you develop the software totally in-house and then release it, this is to some degree comparable to projects like Mozilla. In the Mozilla project the original Netscape developers started out as the designated "module owners" responsible for particular portions of the code, and then as non-Netscape contributors came on board they first contributed patches that were checked in by others, then they could get check-in access themselves (with their code being reviewed by module owners or others) and then finally they had the opportunity to become module owners themselves for particular components. So except for people in your company everybody else starts out "on the outside looking in"; this is unavoidable under this model, and has the effect of stretching out the period before the project is seen as a true open public effort (mostly) independent of your company. (Again, Mozilla is the classic case of this.)
So there are some good reasons to try to get other people outside your company involved relatively early on. Then they can participate as code contributors and module owners for whatever part of the project interests them. As for exercising overall control, you can have a single person overseeing the project or you can try and do a committee-style structure like the Apache folks did.
(The Apache project is one of the most formal ones in terms of their internal organization, and it's probably worth you're checking out what they did with the Apache Software Foundation. Also check out Brian Behlendorf's chapter in the "Open Sources" book, particularly the "Bootstrapping" section, for some information on the types of people you'll need in the course of the project, either from your company or from somewhere else.)
If you want to get people involved early on then you'll need to find people who are motivated to participate at the design stage. You might try looking for existing open source projects that are related to the problem space that your planned software addresses; those projects might have existing software you can reuse, and even more important may have people interested in participating in your project starting at the ground floor. (Even if you develop the software internally you're going to want to do this sort of "market study" anyway, because there's no point in doing work and then finding out that someone else has created a project that duplicates yours and prevents your project attracting developers.)
Another option is actually contracting with independent developers to work on the project in the early development phases, either to supplement your own developers or even to totally outsource the work. (For example, this is what Galactic Marketing did with the open source workflow project they're doing.) Even if you contract work out there's nothing to stop you from running the project "in the open" so others can check it out and provide useful feedback (as indeed happened with the Galactic Marketing project); whether you host the project yourself or somewhere else, you want to have some level of public access so interested observers have an entry point into the project.
That's all the comments I have time for now; good luck with your project!
Well, I'm by no means an expert, but I'll try: M14 was a Mozilla milestone like other milestones, and there will be other milestone releases in the future: M15, M16, etc. After release of M14 and a few days of additional bug fixing, Netscape went onto a Mozilla branch in order to prepare for release of beta 1 of Netscape 6; Netscape will do more bug fixing on that branch, and will then combine the Mozilla code with Netscape-proprietary code (from what is known as the Netscape "commercial tree") to create the Netscape 6 beta 1 release.
Mozilla development and bug fixing continues on the trunk, with contributions from both Netscape developers and others, and is planned to result in an M15 milestone release sometime in April and an M16 milestone release sometime in May. As I understand it, Mozilla bug fixes made by Netscape on their beta 1 branch are being rolled back onto the trunk, and Netscape will use future Mozilla milestones as the basis for future Netscape 6 beta releases and then Netscape 6 production release. (Presumably they will work on branches as necessary to create those releases, just as they are doing now with beta 1.)
In a side issue, once M14 was released the security/crypto developers at iPlanet E-Commerce Solutions (the Sun-Netscape Alliance) used an M14-based branch to add and test changes to Mozilla needed to invoke SSL functionality provided by the separate Netscape Personal Security Manager binaries. As I understand it, those changes have now been rolled back onto the Mozilla trunk and will be in M15. (I think Netscape 6 beta 1 should have those SSL-related changes as well, since they were originally taken from the Netscape commercial tree.)
For more on Netscape's Mozilla-related development plans see the netscape.public.mozilla.s eamonkey newsgroup, in particular the recent posts "Netscape Feature Complete proposal: use 5/2 checkpoint target date" and "M15 will be the next checkpoint build from mozilla" by Jim Roskind of the Netscape client development group.
Also, the Mozilla SSL implementation (in the Personal Security Manager and Network Services Services library) was released under both the MPL and GPL. This was done specifically to allow this code to be used in GPLed software. See the Mozilla Crypto FAQ.
There is no binary-only code hosted on mozilla.org as part of the Mozilla project. The Netscape Personal Security Manager binaries (which provide SSL support for Mozilla) have been provided by iPlanet, because they have the license from RSA to include the necessary code and algorithms to build a complete binary executable ready for use (in this case under the "Netscape" brand).
All of the other code in PSM is or will be available in source form on the mozilla.org site. People who want to use that source code to build their own PSM binaries will be able to do so, as long as they have separate source code to implement the RSA-licensed parts.
For reference, there are three sets of relevant source code needed to provide SSL support for Mozilla:
As always, for more information see the Mozilla Crypto FAQ.
Right, I'm familar with OpenSSL, and yes it is one possible source for implementations of the underlying crypto algorithms, including RSA. There are others as well. The PSM/NSS source code already released by iPlanet (formerly the Sun-Netscape Alliance) or to be released later already includes code for the SSL protocol itself, it needs the crypto code to go underneath SSL.
Mozilla does not yet have support for encrypted email, either S/MIME or PGP-based. I expect both to become available later sometime, but it's too soon to guess at dates.