No subject
Mon Feb 21 17:26:18 CET 2011
may get people enthusiastic about it and willing to help in e.g. code
development and testing. We have examples of this happening already in
the GenABEL project.
I can imagine that one may be afraid that an idea is =93stolen=94.
However, in my opinion, this is highly unlikely to happen: an
individual stealing from peers will be excluded from the community
right away, and will get very bad publicity. =93Stealing=94 things is too
risky a business for one who intends to stay in the field. Mind also
that many ideas are =93in the air=94 and many people come to the same idea
simultaneously and independently (e.g. rediscovery of Mendel=92s lows).
Also please mind that an idea costs very little if it does not
translate to application (e.g. through development of a software). It
is just too easy to come up with =91ideas=92; implementing them, this is
what makes it real (see Edison=92s 1% inspiration and 99% perspiration).
I can also imagine that some people want to do methodology and
software development "in private" for at least some time, because they
are afraid that the idea/implementation will be used without proper
reference/credit. I do not agree with this position: while you indeed
run some risk by making a not-yet-published idea open and usable, I
think the benefits of using community intelligence outweigh the risks.
Secondly, even if you have a method published, only awareness of the
general public about your method can prevent other people from
reinventing "your" methodology and making a great fuss of it. The only
way to get proper credit is to let really many people know about your
idea, to disseminate it effectively. In this, the GenABEL project can
help you.
Now, switching from ideas/methodology to implementation. In this, we
should stick to open source principles, again. My favorite license at
the moment is GNU GPL: anyone is free to copy, modify, and
redistribute the code provided the derivative code carries the same
license (so, free to copy, modify, redistribute; it is recursive in a
way). I also think all committers should have write-rights to the
whole project code (does not mean that someone would/should make
stupid changes in other people=92s code!). Again, my believe is that the
source code should go public as soon as possible.
Here is an example to illustrate above ideas. We have released
ProbABEL for public use in 2008, and it was in wide use ever since.
The ProbABEL paper was published ~1.5 years later, in 2010. And I am
happy we released ProbABEL in that way. A lot of feedback was provided
between 2008 and 2010. Not to mention the 'public good' again, I am
also rather confident that our citation factor will be higher under
this scenario compared to an imaginary scenario under which we would
have postponed the public release of software to 2010 (publication
date).
The next point is about open documentation. When one develops a
tutorial, unless he/she wants to keep it private (?!), I suggest that
it clearly carries the license. What really matters for me in a
license is the fact that other people can use my text as a starting
point for further developments, can modify my text, make derivative
works, and redistribute it (hopefully leading to increasingly better
transmission of ideas, and to public good). Of cause, I also want my
name to be mentioned and get some credit. My current preference is CC
BY-SA (http://creativecommons.org/licenses/; seems like GNU LGPL to
me), and I am going to release =91ABEL tutorial=92 under it or something
similar. Under this license, other people can make derivative works;
this definitely is following open source spirit.
At some point, we may think of publishing our 'community' set of
tutorials and selling printed copies (charging for the fact of
physical transaction of a copy, not for information!). This money can
be used for purposes, which are unequivocally for the good of the
project as the whole, such as e.g. paying the costs of Amazon Cloud
hosting our web-server and forum.
Finally, it will be only fair if a manuscript which has used GenABEL
project as a setting, will appear in open access -- the community has
contributed to the work, and has rights to access the results. I must
admit, though, that the original GenABEL-package paper is not open
access -- back in 2007, this did not seem important. I will try to
make that paper open access, but this will take some time.
Disclaimer. This is my personal position, which is open for
discussion. In this post, I am not speaking on behalf of the GenABEL
project community, but rather seeding the discussion, which will
eventually set the project's broad standards.
I would like to thank Dr. Lennart Karssen for valuable and continuous
discussion through which many of my views on the GenABEL project have
evolved.
More information about the genabel-devel
mailing list