>If the code is freely available, what keeps someone from developing
>an alternative browser based on the same code?
... er, nothing. It's encouraged and happens every day. But there are
rules of use outlined in the MPL and GPL licences.
> It's my understanding
>that the rights to the code are spread out over so many people that
>copyright law does not really control the issue.
It's not really to do with a large number of authors and the
difficulty of legally enforcing copyright but instead that authors in
the Mozilla organisation choose to release their code under a licence.
Mozilla is released under the MPL and GPL licences *. Most countrys'
copyright law says that when it's your property (your code) you can
release it under your own conditions - especially when it's for public
use.
* yeah - "licence licence", but for readibilities sake.
>My question is not just theoretical. My mail client is very powerful,
>totally free, but increasingly complex. It's built by one person.
>He's not crazy about releasing the code, probably for a number of
>reasons but control is likely one of them. I think that open source
>could improve the product and decrease the development time for
>upgrades, but I don't have an answer to the control and quality
>issues. Yet Mozilla must have the answer, because you have all sorts
>of people downloading or working on your product, yet you seem to
>have strict quality and production control. How?
I'm not sure how detailed an answer you want here. You'll notice that
each derivitive Mozilla project has it's own individual name and
website. People just can't immediately make additions to code for
download on these websites. People must be trusted by the project to
be allowed that access, and until they earn this trust they can put
downloads on their own website only. After submitting many code
patches to the project - which may be inspected for quality - they may
gain the trust of the project and may be allowed immediate access to
the original code to modify as they wish. They have earnt this trust.
Some projects don't have these goals of open development, but
regardless, your patches may be put inserted by other project
developers.
When it comes to giving these projects direction you'll often find
road maps. These detail what direction the project intends to develop
towards. These ideas of a direction usually begin in mailing lists,
newsgroups, or IRC. They are usually open for discussion and if you
have an excellent idea about architecture, or a better way of
rendering a nested table, you'll usually find that your ideas are
welcomed and incorporated into the roadmap.
The Mozilla Organisation has procedures about patches (a certain
number of people have to verify that it's good code?). They publish
roadmaps and have rather open discussion.
For your email client's developer - they could write a public roadmap
and regularly give code for download (a public CVS); start a mailing
list to discuss the projects goals and future direction. They still
control what's available for download on [email client].org - which
retains the real power.
Of course someone may set up [email client derivitive].com rather than
contributing and offer a slightly different version. This is a good
thing. With certain licences you can benefit from their development
and incorporate their work back into your own project. Choose your
licence wisely.
So 'open discussion on road maps', 'procedures for patches' are the
main things to decide. Have fun now!
