Hi,
> On Mon, Jun 25, 2012 at 8:55 PM, <pawli...@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
dne...@gnome.org
Jabber: nea...@gmail.com
_______________________________________________
tos mailing list
tos@teachingopensource.org
http://lists.teachingopensource.org/mailman/listinfo/tos
