[TOS] Guidelines on launching an open source project?
joel.sherrill at gmail.com
Wed Jun 27 18:48:31 UTC 2012
I have to agree that without a community, it is just a public
repository for your code.
Are there contributors already from outside organizations? Users?
How will you acquire them?
If you want to attract developers, is the code approachable? Can a
stranger build it?
Is it dependent on something obscure or proprietary? And this includes
Do you have good testing? How will you accept and test submissions?
Does it make sense to have "hands on" sessions at conferences? Would this help
get people involved?
You have to do the license, hosting, etc correctly but without a
community that includes
users and developers, it is just another repository. There are plenty
of dead code
repositories out there. Your goal is a vibrant community around that code.
I am thrilled you are making code available. Just make sure this just
code over the wall. :)
On Wed, Jun 27, 2012 at 11:46 AM, Ivaylo Ganchev
<ivaylo.ganchev at univ-paris8.fr> wrote:
> I would also support that licencing, repository and all the technical
> stuff is a secondary thing that should be correctly addressed, but after
> fixing the primary concerns.
> IMHO it is more important to think about how to gather community and how
> to manage the interactions with it, fix an open source governance, who
> will take the important decisions (community, you, or a common decision),
> do you plan to change the cycles of production while going floss, etc...
> A good document about all these aspects could be found here :
> Please keep us in touch with the project, it sounds interesting.
> Best regards,
> Ivaylo Ganchev
>> ok..just to throw some off the wall stuff into the conversation. i think
>> license and technical infrastructure are not the answer to your
>> question. im pondering this a lot recently and hoping to write an
>> article titled something like "free licenses do not make free software".
>> Trite perhaps but I'm trying to articulate that licenses have very
>> little to do with what comes after. An organisation can employ a free
>> license but act like a proprietary vendor - that will not invite
>> participation involvement, or in some cases, even use of the code.
>> The value and consequently the interesting and challenging opportunities
>> that 'openness' presents lie elsewhere. They reside in the need to
>> determine what "openness" means to your organisation. What exactly do
>> you mean, for example, when you say "maintain control in the statement
>> "maintaining control of the "official" version."
>> The license and technical infrastructure are the easier issues to
>> address. What you want after that is something you should spend some
>> time thinking about and asking if you really know how to achieve it, and
>> if not what are you going to do about it...
>> probably thats not useful...
>> On 06/26/2012 07:59 AM, Allen Tucker wrote:
>>> Hi T. F.,
>>> A popular and simple approach is to set up a Google project at
>>> code.google.com, which you can configure with a Mercurial repository and
>>> control access in the ways that you identify below. (Before setting up
>>> this project, you would need to create a Google id for yourself if you
>>> don't have one already.)
>>> The code in your Mercurial repository can then can be cloned over to
>>> this new repository for others to access and your committers to maintain
>>> as they do now.
>>> Let me know if you need help with any of the details.
>>> Allen Tucker
>>> On Jun 25, 2012, at 11:55 PM,<pawlicki at cs.rochester.edu>
>>> <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.
>>>> Any pointers, guidelines, or advice would be appreciated.
>>>> T. F. Pawlicki
>>>> Dept. Computer Science
>>>> University of Rochester
>>>> tos mailing list
>>>> tos at teachingopensource.org
>>> tos mailing list
>>> tos at teachingopensource.org
>> tos mailing list
>> tos at teachingopensource.org
> tos mailing list
> tos at teachingopensource.org
More information about the tos