Slashdot Mirror

This!

[ A summary of a discussion from http://www.sitepoint.com/open-source-licensing/ and lots of good links re licensing issues. ]

The parent easily spent an hour or few putting that together.

Another good resource is one of the chapters of http://producingoss.com/

I published a project on github a year or couple ago. It is/was in an alpha state and not functional, so there's no huge interest. Figuring out what license to use took some time because of interactions with other efforts. My project makes use of files licensed under the MIT license. I expect to eventually contribute my code to another project that uses what seems to be an ISC license. I need the user to download a library that's only available as source. Not the most complex situation, but researching the license options takes time.

I can imagine that some people want to publish their code, but are either unaware that the default license is "all rights reserved", don't care, or care but don't want to spend the time to figure out what's appropriate.

The default license is "all rights reserved". When you create a new (public) project, github should require you to acknowlege that or to specify a license. A link to a good discussion of licensing issues could be included. The list of licenses to choose from should include "all rights reserved" and "see project-specific license". I'm not sure that "public domain" should be on the list because IIRC you need at least a minimal license to say "no warrenty" and provide a "limitation of liability". Project owners could still leave their code unlicensed.

I'm sad to hear that someone ripped off your work and resold it as their own. That's unjust, and it's one of the inherent risks of open source development.

There is a healthy variant of this where companies build a product based on an open source code base, something that adds value but is doing something that the community around the open source project isn't interested in doing. Many companies do this, including Facebook and Yahoo, who fund development of of e.g. Apache Hadoop, and Apple who are using BSD and Apache-licensed code in OS X. If you're doing this well, you feed back any changes the community might be interested in. And that doesn't mean just dropping some code on their lists and walking away. You need to interact nicely, react to community feedback, and eventually become part of the community and share some responsibility.

Whoever sold your work as their own took the irresponsible and damaging route with the above approach, looking for short-term profit only, with no interest in supporting the original project. To fight this, you can use a copyleft licence and enforce it if it is violated, and/or build a community that is strong and dedicated to supporting the original product (this is why new projects at the Apache Software Foundation go through an incubating phase that builds up a community around the project -- the project graduates once the community is deemed healthy). As an additional lever, you could also trademark your product's name to ensure that others who use your work cannot use the same name for their own product but must rebrand it.

You can also sell services that relate to the software. E.g. where I work we sell support and consulting for open source development tools (svn, git, eclipse, and the like). We also contribute to some of the projects we sell services for, so money people pay for our services partly funds further development of these open source tools. We make sure clients are aware of that, and they are usually quite happy about getting support from someone who is a developer on the project. This gives us a small competitive edge over others who sell consulting for these open source products but don't interact with the open source community.

An excellent description of the role money can play in an open source project is given by Karl Fogel at http://www.producingoss.com/en/money.html

.

[Note: The summary's second link seems to be getting slashdotted, so I'm copying its contents to a comment here. The words are not my own.]

This entry was posted by Ben Collins-Sussman on Monday, 3 January, 2011

Author’s Note: These opinions are my own. I'm one of the original folks that started the Subversion project, but no longer work on it. These thoughts do not reflect the official position of either the Subversion project or the Apache Software Foundation, which are located here on the ASF blog.

Subversion has reached the realm of Mature software — it’s yesterday’s technology, not cool or hip to work on anymore. It moves slowly. It is developed almost entirely by engineers working for corporations that need it or sell support for it. Alpha-geeks consider software like this “dead”, but the fact is that something like half of all corporate programmers use Subversion as their SCM (depending on which surveys you read.) This is a huge userbase; it may not be sexy, but it’s entrenched and here for the long haul.

Subversion isn’t unique in this position. It sits alongside other mature software such as Apache HTTPD or the GCC toolchain, which are famous projects that are similarly developed by corporate interests. There’s a tricky line to walk: none of these corporations “own” these projects. They understand that they’re acting as part of a consortium. Each interest sends representatives to the open source project, contributes code, and allows their engineers to participate in the full consensus-based evolution of the software. IBM, Apple, Google, and numerous other companies have figured out how to do this correctly:

• 1. Let your engineers know what’s important to work on.
• 2. Let them participate individually in the community process as usual.
• 3. Profit. 98% of the time the corporations eventually get the features they want.

Today, however, we have a great counterexample of how not to participate in an open source project. Subversion was initially funded and developed by CollabNet; today at least two other companies — Elego and WANdisco — are employing numerous engineers to improve Subversion, and are just as vested in selling support and derivative products. CollabNet and Elego continue to function normally in the community, but WANdisco recently seems to have lost its marbles. Last week, they put out a press release and a CEO blogpost making some crazy statements.

It’s clear that the WANdisco CEO — David Richards — is frustrated at the slow pace at which Subversion is improving. But the two posts are simply making outrageous claims, either directly or via insinuation. David seems to believe that a cabal is preventing Subversion from advancing, and that “debate” is the evil instrument being used to block progress. He believes users are crying for the product to be improved, that the Subversion developers are ignoring them, and his company is now going to ride in on a white horse to save the project. By commanding engineers to Just Fix things, he’ll “protect the future”of Subversion, “overhauling” Subversion into a “radical new” product.

Is this guy for real? It sounds like someone read my friend Karl's book and created a farce of “everything you’re not supposed to do” when participating in corporate open source.

Even weirder, he’s accusing developers of trying game statistics by creating lots of

I highly recommend you read the announcing security vulnerabilities section of Producing Open Source Software book. You'll probably want to read the whole thing, however!

I highly recommend you read the announcing security vulnerabilities section of Producing Open Source Software book. You'll probably want to read the whole thing, however!

Reading through a lot of the replies, I think it would help a lot of people to understand the two most prevalent kinds of political and social infrastructure for open source projects: benevolent dictator and consensus-based democracy. Karl Fogel, in his excellent book, Producing Open Source Software (O'Reilly) -- which itself is open source and available for free download -- summarizes them extremely well. Reading TFA and replies, it seems to me that this is a really good case study in how an open source project is managed. I highly recommend reading Karl's section on Political and Social Infrastructure. I'll include two relevant excerpts, because I think they shine light on exactly this situation.

From his section on benevolent dictators:

The benevolent dictator model is exactly what it sounds like: final decision-making authority rests with one person, who, by virtue of personality and experience, is expected to use it wisely.

Although "benevolent dictator" (or BD)is the standard term for this role, it would be better to think of it as "community-approved arbitrator" or "judge". Generally, benevolent dictators do not actually make all the decisions, or even most of the decisions. It's unlikely that one person could have enough expertise to make consistently good decisions across all areas of the project, and anyway, quality developers won't stay around unless they have some influence on the project's direction. Therefore, benevolent dictators commonly do not dictate much. Instead, they let things work themselves out through discussion and experimentation whenever possible. They participate in those discussions themselves, but as regular developers, often deferring to an area maintainer who has more expertise. Only when it is clear that no consensus can be reached, and that most of the group wants someone to guide the decision so that development can move on, do they put their foot down and say "This is the way it's going to be." Reluctance to make decisions by fiat is a trait shared by virtually all successful benevolent dictators; it is one of the reasons they manage to keep the role.

and on consensus-based democracy:

As projects get older, they tend to move away from the benevolent dictatorship model and toward more openly democratic systems. This is not necessarily out of dissatisfaction with a particular BD. It's simply that group-based governance is more "evolutionarily stable", to borrow a biological metaphor. Whenever a benevolent dictator steps down, or attempts to spread decision-making responsibility more evenly, it is an opportunity for the group to settle on a new, non-dictatorial system—establish a constitution, as it were. The group may not take this opportunity the first time, or the second, but eventually they will; once they do, the decision is unlikely ever to be reversed. Common sense explains why: if a group of N people were to vest one person with special power, it would mean that N - 1 people were each agreeing to decrease their individual influence. People usually don't want to do that. Even if they did, the resulting dictatorship would still be conditional: the group anointed the BD, clearly the group could depose the BD. Therefore, once a project has moved from leadership by a charismatic individual to a more formal, group-based system, it rarely moves back.

The details of how these systems work vary widely, but there are two common elements: one, the group works by consensus most of the time; two, there is a formal voting mechanism to fall back on when consensus cannot be reached.

Reading through a lot of the replies, I think it would help a lot of people to understand the two most prevalent kinds of political and social infrastructure for open source projects: benevolent dictator and consensus-based democracy. Karl Fogel, in his excellent book, Producing Open Source Software (O'Reilly) -- which itself is open source and available for free download -- summarizes them extremely well. Reading TFA and replies, it seems to me that this is a really good case study in how an open source project is managed. I highly recommend reading Karl's section on Political and Social Infrastructure. I'll include two relevant excerpts, because I think they shine light on exactly this situation.

From his section on benevolent dictators:

The benevolent dictator model is exactly what it sounds like: final decision-making authority rests with one person, who, by virtue of personality and experience, is expected to use it wisely.

Although "benevolent dictator" (or BD)is the standard term for this role, it would be better to think of it as "community-approved arbitrator" or "judge". Generally, benevolent dictators do not actually make all the decisions, or even most of the decisions. It's unlikely that one person could have enough expertise to make consistently good decisions across all areas of the project, and anyway, quality developers won't stay around unless they have some influence on the project's direction. Therefore, benevolent dictators commonly do not dictate much. Instead, they let things work themselves out through discussion and experimentation whenever possible. They participate in those discussions themselves, but as regular developers, often deferring to an area maintainer who has more expertise. Only when it is clear that no consensus can be reached, and that most of the group wants someone to guide the decision so that development can move on, do they put their foot down and say "This is the way it's going to be." Reluctance to make decisions by fiat is a trait shared by virtually all successful benevolent dictators; it is one of the reasons they manage to keep the role.

and on consensus-based democracy:

As projects get older, they tend to move away from the benevolent dictatorship model and toward more openly democratic systems. This is not necessarily out of dissatisfaction with a particular BD. It's simply that group-based governance is more "evolutionarily stable", to borrow a biological metaphor. Whenever a benevolent dictator steps down, or attempts to spread decision-making responsibility more evenly, it is an opportunity for the group to settle on a new, non-dictatorial system—establish a constitution, as it were. The group may not take this opportunity the first time, or the second, but eventually they will; once they do, the decision is unlikely ever to be reversed. Common sense explains why: if a group of N people were to vest one person with special power, it would mean that N - 1 people were each agreeing to decrease their individual influence. People usually don't want to do that. Even if they did, the resulting dictatorship would still be conditional: the group anointed the BD, clearly the group could depose the BD. Therefore, once a project has moved from leadership by a charismatic individual to a more formal, group-based system, it rarely moves back.

The details of how these systems work vary widely, but there are two common elements: one, the group works by consensus most of the time; two, there is a formal voting mechanism to fall back on when consensus cannot be reached.

Reading through a lot of the replies, I think it would help a lot of people to understand the two most prevalent kinds of political and social infrastructure for open source projects: benevolent dictator and consensus-based democracy. Karl Fogel, in his excellent book, Producing Open Source Software (O'Reilly) -- which itself is open source and available for free download -- summarizes them extremely well. Reading TFA and replies, it seems to me that this is a really good case study in how an open source project is managed. I highly recommend reading Karl's section on Political and Social Infrastructure. I'll include two relevant excerpts, because I think they shine light on exactly this situation.

From his section on benevolent dictators:

The benevolent dictator model is exactly what it sounds like: final decision-making authority rests with one person, who, by virtue of personality and experience, is expected to use it wisely.

Although "benevolent dictator" (or BD)is the standard term for this role, it would be better to think of it as "community-approved arbitrator" or "judge". Generally, benevolent dictators do not actually make all the decisions, or even most of the decisions. It's unlikely that one person could have enough expertise to make consistently good decisions across all areas of the project, and anyway, quality developers won't stay around unless they have some influence on the project's direction. Therefore, benevolent dictators commonly do not dictate much. Instead, they let things work themselves out through discussion and experimentation whenever possible. They participate in those discussions themselves, but as regular developers, often deferring to an area maintainer who has more expertise. Only when it is clear that no consensus can be reached, and that most of the group wants someone to guide the decision so that development can move on, do they put their foot down and say "This is the way it's going to be." Reluctance to make decisions by fiat is a trait shared by virtually all successful benevolent dictators; it is one of the reasons they manage to keep the role.

and on consensus-based democracy:

As projects get older, they tend to move away from the benevolent dictatorship model and toward more openly democratic systems. This is not necessarily out of dissatisfaction with a particular BD. It's simply that group-based governance is more "evolutionarily stable", to borrow a biological metaphor. Whenever a benevolent dictator steps down, or attempts to spread decision-making responsibility more evenly, it is an opportunity for the group to settle on a new, non-dictatorial system—establish a constitution, as it were. The group may not take this opportunity the first time, or the second, but eventually they will; once they do, the decision is unlikely ever to be reversed. Common sense explains why: if a group of N people were to vest one person with special power, it would mean that N - 1 people were each agreeing to decrease their individual influence. People usually don't want to do that. Even if they did, the resulting dictatorship would still be conditional: the group anointed the BD, clearly the group could depose the BD. Therefore, once a project has moved from leadership by a charismatic individual to a more formal, group-based system, it rarely moves back.

The details of how these systems work vary widely, but there are two common elements: one, the group works by consensus most of the time; two, there is a formal voting mechanism to fall back on when consensus cannot be reached.

Reading through a lot of the replies, I think it would help a lot of people to understand the two most prevalent kinds of political and social infrastructure for open source projects: benevolent dictator and consensus-based democracy. Karl Fogel, in his excellent book, Producing Open Source Software (O'Reilly) -- which itself is open source and available for free download -- summarizes them extremely well. Reading TFA and replies, it seems to me that this is a really good case study in how an open source project is managed. I highly recommend reading Karl's section on Political and Social Infrastructure. I'll include two relevant excerpts, because I think they shine light on exactly this situation.

From his section on benevolent dictators:

The benevolent dictator model is exactly what it sounds like: final decision-making authority rests with one person, who, by virtue of personality and experience, is expected to use it wisely.

Although "benevolent dictator" (or BD)is the standard term for this role, it would be better to think of it as "community-approved arbitrator" or "judge". Generally, benevolent dictators do not actually make all the decisions, or even most of the decisions. It's unlikely that one person could have enough expertise to make consistently good decisions across all areas of the project, and anyway, quality developers won't stay around unless they have some influence on the project's direction. Therefore, benevolent dictators commonly do not dictate much. Instead, they let things work themselves out through discussion and experimentation whenever possible. They participate in those discussions themselves, but as regular developers, often deferring to an area maintainer who has more expertise. Only when it is clear that no consensus can be reached, and that most of the group wants someone to guide the decision so that development can move on, do they put their foot down and say "This is the way it's going to be." Reluctance to make decisions by fiat is a trait shared by virtually all successful benevolent dictators; it is one of the reasons they manage to keep the role.

and on consensus-based democracy:

As projects get older, they tend to move away from the benevolent dictatorship model and toward more openly democratic systems. This is not necessarily out of dissatisfaction with a particular BD. It's simply that group-based governance is more "evolutionarily stable", to borrow a biological metaphor. Whenever a benevolent dictator steps down, or attempts to spread decision-making responsibility more evenly, it is an opportunity for the group to settle on a new, non-dictatorial system—establish a constitution, as it were. The group may not take this opportunity the first time, or the second, but eventually they will; once they do, the decision is unlikely ever to be reversed. Common sense explains why: if a group of N people were to vest one person with special power, it would mean that N - 1 people were each agreeing to decrease their individual influence. People usually don't want to do that. Even if they did, the resulting dictatorship would still be conditional: the group anointed the BD, clearly the group could depose the BD. Therefore, once a project has moved from leadership by a charismatic individual to a more formal, group-based system, it rarely moves back.

The details of how these systems work vary widely, but there are two common elements: one, the group works by consensus most of the time; two, there is a formal voting mechanism to fall back on when consensus cannot be reached.

I would go further than just publishing the code used in scientific research. I would build the code by running it a real open source project. In fact, I've done exactly that, and it worked out incredibly well. I believe our open source approach lead to better science, and also better software.

I worked with researchers from MIT and Columbia on a research project that involved gathering and analyzing a large amount of publication data. The results of the study are about to be published (you can read the working paper at the lead researcher's website).

We intended the code for this project to be released from the beginning, so we ran it as an open source project. I followed the basic formula from Karl Fogel's excellent (and free to download) book, Producing Open Source Software: set up a website for the project, created lots of documentation, tried to make it as easy as possible for someone to get up and running, made the source available via Subversion, and made it easy to contact us.

Quality was really important for us, so we put a lot of effort into testing. I definitely believe that the fact that we intended the project to be open source from the beginning helped with that. We weren't treating the code as some piece of throwaway or replaceable lab equipment. I'm convinced that treating it as a real product of the research caused us to take the development and the quality much more seriously than a lot of researchers. I've since heard from other researchers who are starting to use the software as well, and everyone who sees it feels that it came out really well.

There was another scientific benefit that should definitely appeal to anyone who lives in the publish-or-perish world of science research. We published a paper specifically on the project (Azoulay P, Stellman A, Zivin JG. PublicationHarvester. An open-source software tool for science policy research. Research Policy 35 (2006) 970-974. -- there's a link to the PDF on the lead researcher's website.)

It's funny -- I wrote an article a few years ago with Jennifer Greene for O'Reilly ONLamp called What Corporate Projects Should Learn from Open Source. I'm now convinced that science research projects can also learn a great deal from open source as well.

• Thinking in C++ by Bruce Eckel http://mindview.net/Books/TICPP/ThinkingInCPP2e.html
• Computer Networks by Andrew Tanenbaum http://www.prenhall.com/tanenbaum/details2.html
• Structured Computer Organization by Andrew Tanenbaum http://www.pearsonhighered.com/educator/academic/product/0,,0131485210,00%2Ben-USS_01DBC.html
• Producing Open Source Software by Karl Fogel http://producingoss.com/
• Design and Implementation of the FreeBSD Operating System by Marshall Kirk McKusick and George V. Neville-Neil http://www.mckusick.com/books.html
• Code Quality by Diomidis Spinellis http://www.spinellis.gr/codequality/

I'm about to finish my fourth book for O'Reilly, Beautiful Teams: Inspiring and Cautionary Tales from Veteran Team Leaders (which should be out in stores by March).

As far as tools go, my coauthor, Jenny, and I wrote our first book using Microsoft Word, but could just as easily have been using OpenOffice, Pages or any other word processor. One thing that was enormously useful was EndNote for managing the bibliography. Our next two books were in O'Reilly's Head First series (PMP and C#), and we wrote them entirely in Adobe InDesign. (People think that there's a whole team of people designing and laying out Head First books -- it was just us, our editor, and an awesome but overworked graphic designer, Lou, who helped improve our layouts once we had them in reasonable shape.) InDesign isn't exactly the easiest tool for a book author, but it was sufficient. But it made me really appreciate word processors!

A few things that really became clear to me over the course of working on these books:

a) Pay attention to what you're delivering to your editor, and what they'll do with it. Publishers have their own set of templates and production stuff to get camera-ready copy together. Head First was a very interesting lesson in that, because Jenny and I actually produced a lot of camera-ready copy ourselves. But for most books, whatever you turn over to your publisher will get transmogrified into their own internal format.

b) The production editor people I've worked with and talked to (not just at O'Reilly, but at other publishers, too) have been extremely competent, and it's their job to take whatever it is you give them and make it work. It needs to be copyedited, typeset, and reviewed, and sent to a printer. I highly recommend getting to know them, and being as flexible and agreeable as possible (they generally won't ask you to compromise your vision for the book -- it's generally about technical stuff, like how to deal with footnotes, references, images, etc.)

c) You asked about version control. One of the best authors I've ever worked with, Karl Fogel -- he's a contributor to Beautiful Teams, and also just a great guy -- wrote a fantastic book called Producing Open Source Software, which you can buy from O'Reilly or download for free from the website. (Anyone who's interested in starting or contributing to an open source project absolutely needs to read that book. Disclosure: I was a technical reviewer for it.) In true open source fashion, Karl made his version control repository for the book available, and that's a good model to copy. Jenny and I didn't do anything quite so formalized; we just shared folders, and that was sufficient for us (even with hundreds and hundreds of image files for each Head First book).

d) This is the most important thing: make sure you have a clear idea of what it is you want to write! It's easy to get started on a project, only to have it trail off because you don't really have a whole book's worth of material. The more you can outline, the more research you do, and the more you prepare, the better the book will be.

Now, that's all assuming that you have a publisher lined up and a contract signed. If you don't, I highly recommend reading through the excellent Writing for O'Reilly section on their website. They walk you through all of the steps of proposing a book and the mechanics of actually working with a publisher -- and from everyone I've talked to, it's very similar

I'm about to finish my fourth book for O'Reilly, Beautiful Teams: Inspiring and Cautionary Tales from Veteran Team Leaders (which should be out in stores by March).

As far as tools go, my coauthor, Jenny, and I wrote our first book using Microsoft Word, but could just as easily have been using OpenOffice, Pages or any other word processor. One thing that was enormously useful was EndNote for managing the bibliography. Our next two books were in O'Reilly's Head First series (PMP and C#), and we wrote them entirely in Adobe InDesign. (People think that there's a whole team of people designing and laying out Head First books -- it was just us, our editor, and an awesome but overworked graphic designer, Lou, who helped improve our layouts once we had them in reasonable shape.) InDesign isn't exactly the easiest tool for a book author, but it was sufficient. But it made me really appreciate word processors!

A few things that really became clear to me over the course of working on these books:

a) Pay attention to what you're delivering to your editor, and what they'll do with it. Publishers have their own set of templates and production stuff to get camera-ready copy together. Head First was a very interesting lesson in that, because Jenny and I actually produced a lot of camera-ready copy ourselves. But for most books, whatever you turn over to your publisher will get transmogrified into their own internal format.

b) The production editor people I've worked with and talked to (not just at O'Reilly, but at other publishers, too) have been extremely competent, and it's their job to take whatever it is you give them and make it work. It needs to be copyedited, typeset, and reviewed, and sent to a printer. I highly recommend getting to know them, and being as flexible and agreeable as possible (they generally won't ask you to compromise your vision for the book -- it's generally about technical stuff, like how to deal with footnotes, references, images, etc.)

c) You asked about version control. One of the best authors I've ever worked with, Karl Fogel -- he's a contributor to Beautiful Teams, and also just a great guy -- wrote a fantastic book called Producing Open Source Software, which you can buy from O'Reilly or download for free from the website. (Anyone who's interested in starting or contributing to an open source project absolutely needs to read that book. Disclosure: I was a technical reviewer for it.) In true open source fashion, Karl made his version control repository for the book available, and that's a good model to copy. Jenny and I didn't do anything quite so formalized; we just shared folders, and that was sufficient for us (even with hundreds and hundreds of image files for each Head First book).

d) This is the most important thing: make sure you have a clear idea of what it is you want to write! It's easy to get started on a project, only to have it trail off because you don't really have a whole book's worth of material. The more you can outline, the more research you do, and the more you prepare, the better the book will be.

Now, that's all assuming that you have a publisher lined up and a contract signed. If you don't, I highly recommend reading through the excellent Writing for O'Reilly section on their website. They walk you through all of the steps of proposing a book and the mechanics of actually working with a publisher -- and from everyone I've talked to, it's very similar

We get this question on the Head First C# forum every now and then from people who read the book, finish it, and want to know what to do next to get a programming career. Here's the post I usually send people to. One thing I think new developers should think about is working on a team -- that's a skill that takes practice, and doesn't always come easy to developers. The better you are at it, the more successful you'll be in your career. (I've got a few tips in that post for getting that kind of experience. Contributing to an open source project is definitely a good start. Karl Fogel's excellent book, Producing Open Source Software, is a great way to learn about how to do that effectively.)

Karl Fogel of Subversion fame has written Producing OSS which contains many good pointers on how to run a OSS project. Perhaps you can find some pointers there.

This is worth reading:

http://producingoss.com/

While the subtitle for Karl Fogel's _Producing Open Source Software_ is "How to Run a Successful Free Software Project", the reviews on Amazon suggest it is good for participants as well. It's available for free at http://producingoss.com/ and is fairly inexpensive if you want it in paper form. I worked with Mr. Fogel at CollabNet and he's first-rate at this, so while I haven't read the book (it's on my to-be-read pile...), I suspect it may prove useful to you.

Lots of great suggestions already. You might also want to read a good book on best practices for open source development projects. Karl Fogel's "Producing Open Source Software" is excellent and available in print form or free online here.

Read _Producing Open Source Software_ by Karl Fogel. You can read it online at http://producingoss.com/.

He's got lots of good advice, and it's from somebody who knows.

-AC

Start by reading Producing Open Source Software. Setup Trac or use Google Code Project Hosting. Make sure it's something you're really interested in doing and committed to spending a lot of time on it. Other people probably won't volunteer their time if they don't see at least one other person strongly committed to the project.

Will you be engaging an external development community as part of this contract? Will you be writing new code from scratch, or integrating it into an existing codebase (and if so, is that existing codebase already open source or not)?

Retaining copyright for yourself is a good idea; you can just make sure the contract grants the other party "perpetual, royalty-free, non-exclusive, irrevocable rights to use, sublicense, and distribute the software" or something like that (I am not a lawyer, though -- and you might want to take out the 'sublicense', depending on your goals, consult a lawyer about that).

I wrote a little bit about this process in

      http://producingoss.com/html-chunk/contracting.htm l

by the way.

Good luck,
-Karl

If you're actually looking for open source collaboration tips, take a look at Karl Fogel's (freely-available) book:

http://producingoss.com/html-chunk/index.html

BSDi / FreeBSD / OpenBSD / NetBSD / Dragonfly

and, of course, the definitive pre-emptive fork :

Minix / Linux

Others I can think of

Mozilla / Firefox

Postgres / Postgres95 (now PostgreSQL)

Can I count OS/2 / Windows ?

Debian / Ubuntu

While I was googling for forks I found these :

http://mako.cc/writing/to_fork_or_not_to_fork.html

http://producingoss.com/html-chunk/forks.html

I don't understand Groklaw's beef.

OK. Hopefully I can help fill in the blanks. :)

She (PJ) was asked two questions. Her first answer was one of the main points of the article: hierarchy is an integral part of successful open source development.

The tone of the Economist's article was that this meant that OSS had failed somehow because they had to be organized the same way that businesses are organized:

However, it is unclear how innovative and sustainable open source can ultimately be. The open-source method has vulnerabilities that must be overcome if it is to live up to its promise. For example, it lacks ways of ensuring quality and it is still working out better ways to handle intellectual property.

But the biggest worry is that the great benefit of the open-source approach is also its great undoing. Its advantage is that anyone can contribute; the drawback is that sometimes just about anyone does. This leaves projects open to abuse, either by well-meaning dilettantes or intentional disrupters. Constant self-policing is required to ensure its quality.

Clearly, the writer had never read Producing Open Source Software:How to Run a Sucessful Free Software Project. The book does a fine job of explaining that yes, some projects do attempt to run as some sort of anarchistic society. Most if not all of those projects fail. People are still people, after all. They still need a community with a strong leadership in order to succeed at any long term project. Why did the writer not know this? Why the assumption that this meant OSS had failed?

As for the factual inaccuracies, what exactly were they? The fact that the author didn't get the "groklaw-approved" exact wording right for telling us SCO is suing IBM, DaimlerChrysler and Autozone?

Oh, come on! You're kidding, right? Here's what the Economist article said:

But more troubling is copyright: if the code comes from many authors, who really owns it? This issue took centre stage in 2003, when a company called SCO sued users of Linux, including IBM and DaimlerChrysler, saying that portions of the code infringed its copyrights. The lines of programming code upon which SCO based its claims had changed owners through acquisitions over time; at some point they were added into Linux.

To sceptics, the suit seems designed to thwart the growth of Linux by spreading unease over open source in corporate boardrooms--a perception fuelled by Microsoft's involvement with SCO. The software giant went out of its way to connect SCO with a private-equity fund that helped finance the lawsuits, and it paid the firm many millions to license the code. Fittingly, Microsoft indemnifies its customers against just this sort of intellectual-property suit--something that open-source products are only starting to do.

For the moment, users of Linux say that SCO-like worries have not affected their adoption of open-source software. But they probably would be leery if, over time, the code could not be vouched for. In response, big open-source projects such as Linux, Apache and Mozilla have implemented rigid procedures so that they can attest to the origins of the code. In other words, the openness of open source does not necessarily mean it is anonymous. Strikingly, even more monitoring of operations is required in open source than in other sorts of businesses.

Here's what PJ said in response:

Heh heh. Not exactly. IBM wasn't sued for using Linux. It was sued for contributing code to Linux. SCO mainly is suing IBM by means of a theory of contract, as best as anyone can make out, a ladder theory by which somehow the contract can be interpreted in a novel way so that any code IBM writes, if it ever touches UNIX SystemV, or

First, check out the book Producing Open Source Software, I found it to be a very informative read. As a starting place, your website needs a little help. It's a little bland but that's not the big problem. It needs to be obvious right-away how I, as someone interested in the project, can get involved. You have the mailing list info which is a good start but a look through the archives proves to be quite lacking activity. Your three target groups are end-users, hackers, and developers. How would someone start "hacking" or just playing with your software? Give them some documentation. What is the process for becoming a developer? Where do I submit patches, how do I get commit access to the repository? Where do I submit bug reports?

You need to also ask yourself if you're really ready to release this as an open source project. I don't mean literally under an open source license, like you have done. I mean, are you ready to let a community of developers and users take control of your project and take it in directions you may have not considered? It's been your baby so far (from what I can tell) so this could be quite a change for you but the rewards could be great.

Well, there's "Producing Open Source Software: How to Manage a Successful Free Software Project", by yours truly. It's just been published by O'Reilly, and it's online at http://producingoss.com/. It's under a CreativeCommons license, so yes, the book itself is open source :-). Hmmm, let's make that URL stand out a bit more:

      http://producingoss.com/

There. Hope this helps!

-Karl Fogel

Well, there's "Producing Open Source Software: How to Manage a Successful Free Software Project", by yours truly. It's just been published by O'Reilly, and it's online at http://producingoss.com/. It's under a CreativeCommons license, so yes, the book itself is open source :-). Hmmm, let's make that URL stand out a bit more:

      http://producingoss.com/

There. Hope this helps!

-Karl Fogel

This is a completely shameless bit of self-promotion, but:

      http://producingoss.com/

That's the web site for the new O'Reilly book "Producing Open Source Software: How to Manage a Successful Free Software Project". The book's content is all there online, under an open copyright. Even when I was writing it, I was thinking of the classroom as one place where the book might be useful. Have a look and see what you think.

Best,
-Karl Fogel