Open Source for SETI Software?

CommonModeNoise asks: "The SETI Institute is thinking about going to an open source model for some of our software. We have little experience with Open Source so we would like to ask the following: To what degree can an open-source project be self-managing -- how many of our staff will be needed to keep such an activity running productively? How can we deal with the lunatic fringe that will be attracted to something as provocative as SETI? Can open source development proceed at the same speed as traditional in-house development, or will it be slower? Some of our software controls hardware, for example the Allen Telescope Array; can such control software be developed using open source methods or are we better off focussing on the software-only systems, such as the next generation of our signal detectors? Finally, could we please get some suggestions as to what to read to get a better grasp of the varieties of open source development models and their respective good and bad points."

Comments

Well, control access to your CVS sources

[orthogonal]

You'd better control access to your CVS sources.

Specifically, don't let the Grays from Cygnus Prime access the source code.

They are deceivers!

They have put a chip in my head and they tell to do bad things. Like to post to Slashdot.

Good Reading Material

[ninjadroid]

Eric S. Raymond has written a few papers on open source design methodologies and the benefits thereof. Check them out at his website. In particular, The Cathedral and the Bazaar is a very enlightening read.

development speed

[DeadSea]

If you are hoping that making your software open source will attract developers, it probably won't. You will very likely have to keep your development team at the current size. The mozilla project experienced this. They thought that when they open sourced the web browser, everybody would start improving it. They didn't. Finally, some outside developers contribute to Mozilla, but it took several years for a very high visibility product.

I don't think that many people would be willing to get up to speed on your development to help you out. There isn't much they will get out of it; developers usually code to scratch an itch. You might get somebody that does a better visual representation or somebody that tries to do some optimization to get better results for themselves, but you will be very lucky to get that.

On the other hand, why wouldn't you go open source? For the most part it can't hurt. You are not trying to sell your software. What if some other observatory realized that they could control their telescopes with your code? They might just do so and find that they could make improvements to your code. Other than the cheating issues with Seti, I can't think of much of anything. And then again, it is well known how to cheat anyway.

"Self Managing"?

[mbrubeck]

I'm not sure where you got the idea that an open-source project could be "self-managing." Any open-source project with more than one contributor takes a significant amount of management. You have two scenarios:

1. Most of your development remains in-house but you get occasional outside contributions, or
2. A community of volunteers takes over most of the development tasks.

Number 1 is much more likely, and would leave you with the same management responsibilities as before, plus the extra job of communicating and coordinating with external contributors. You need to make your own development open to the community (make your mailing lists and code repositories public, give frequent updates on your status), and you need to give instant and useful feedback to developers who contact you with questions or contributions.

Number 2 will happen only if you are lucky. It will leave you with an even bigger management burden because you have no control over the outside developers, and much less coordination unless you do a really good job of managing and communicating with the community. If you want to make sure that your organization's needs are still met, you need to encourage contributions in the right areas without discouraging people from joining your project. You have to deal with the possibility of the community forking the code and drawing effort away from your goals. You have to keep everyone working together even though you and they have never met face-to-face.