[TOS] Guidelines on launching an open source project?

[Dave Neary]

Hi,

 > On Mon, Jun 25, 2012 at 8:55 PM,  <pawlicki at cs.rochester.edu> wrote:
 >>
 >>    I been asked to help take a fairly extensive body of code and
 >> release it as an open source project.
 >>
 >> I'm wondering if someone can point me to some resources that
 >> might guide us along this process?
 >>
 >>   My collaborators have a body of code used for physics simulation.
 >> It's all under Mercurial for internal management. They want to
 >> distribute it under an open source model, while maintaining control
 >> of the "official" version.

On 06/27/2012 07:33 PM, Cat Allman wrote:
> I would suggest taking a look at Karl Fogel's book "Producing Open
> Source Software" at http://producingoss.com/  There's lots of info in
> there.

Excellent suggestion Cat!

One of the key points Karl makes early is: "Think about what you're 
trying to accomplish, and why it matters" (that is a paraphrase on my 
part). And this is the key point. What do you want to accomplish, and 
why will it matter to you (and others).

The next question is: how is my project social? Communities build up 
around social interaction related to a common goal or vision. So your 
infrastructure needs will be dictated by the type of social 
relationships people will have - colleagues working on a shared 
code-base together, sharing extensions they've found useful, or sharing 
knowledge about your project and how to integrate it with other 
projects? Each of these types of communities has different needs in 
terms of infrastructure, whether it's a place to share their stuff, a 
mailing list for communication, a forum or IRC channel for real-time 
communication or a wiki for longer-term memory.

The licence of the code and its availability on source control does make 
it open source, but the other stuff is what allows you to grow a community.

My suggestion to your colleagues would be to work on the upstream one, 
and then at some given point make a private branch from which they 
stabilise their official release, rather than the other way around. 
"control of the official version" implies rejecting something from "the 
community" at some point. Better to have a community version which is 
close to free-for-all to begin with, while seeding the community, and 
then work on building your private version from the free-for-all base. 
The important point is that most of your resources should be going 
upstream, to the community project, rather than into your private 
version. And to help you set expectations appropriately, the likelihood 
of significant community contribution in the first 12 - 24 months, even 
if you do everything right, is slim.

Hope that helps!
Dave.




-- 
Dave Neary
GNOME Foundation member
dneary at gnome.org
Jabber: nearyd at gmail.com