> what's be benefit of thinking AMBER as a whole package rather a suite of
> difference packages?
> why do we really need to centralize it? and why pain?
>
http://www.clarity-in-communication.com/getattachment/e69c0b29-934a-4b13-9f8f-d6a1d6274cfc/A-strong-brand.aspx
Branding, branding, branding... People respect the AMBER developers (at least I hope they do), they respect and they trust the software.
Also take a look at things like this: https://scholar.google.com/scholar?oi=bibs&hl=en&cites=1359192529121551417
Amber gets thousands of citations. People who make solid contributions should be included on the author list and benefit from being associated with all of these citations.
Try creating a stand alone tool - say pytraj - in isolation from Amber - see how many citations you get vs if you include it as part of Amber.
Without a doubt it will get way more exposure and use and subsequently your scientific career will ultimately benefit if it is part of the wider AMBER development effort and you are considered part of the AMBER development team. If that is not the case then we should all just give up now and go our separate ways.
> taking cpptraj as example (since people know it):
>
> 1. centralized AMBER: if people want to add code to cpptraj
> + clone amber repo
> + make a new branch, make code change, recompile, do a bunch of testings
> with different combinations
> + merge to ambe master branch, push to remote
>
> 2. github: if people want to add code to cpptraj
> + clone cpptraj repo on github
> + make a new branch, make code change, push to github and let travis do all
> the testing. No worry about old computer.
> + Dan will review code, merge code if he thinks ok
> + merge back to amber repo, push to remote.
>
> The only difference I can think of is that package manager (Dan for
> cpptraj) needs to approve the code change (which is good) + many advantages
> using travis.
>
This sounds reasonable - for an isolated case - expand that to every package and we have a complete mess. We also dilute the concept of the AMBER brand and the AMBER development team. Ultimately everyone that is associated with the AMBER team benefits from cpptraj being part of AMBER. That's the ultimate benefit here. We are way stronger as a collective than we are as a bunch of individual projects. I know Dan says the github branch is part of AMBER but I am not sure that message will always get propagated properly going forward and it definitely will become harder if we all go down this individualist route. For starters people will likely say things in a paper like: We used the github version of cpptraj[ref link to cpptraj github page accessed on blah - they 'might' also cite the cpptraj paper but there are many example tools in AMBER that don't have standalone publications] - bang there goes the AMBER citation - everybody loses [except maybe Dan].
> Note: If anyone does not like github, they can still edit cpptraj code in
> amber repo (but not encouraged to do so).
It's not about liking or not liking github. It is that we need to preserve the concept of AMBER as a package and the idea of a coherent AMBER development team. If we have a public repository it should reflect this unity.
My 0.02 BTC
All the best
Ross
/\
\/
|\oss Walker
---------------------------------------------------------
| Associate Research Professor |
| San Diego Supercomputer Center |
| Adjunct Associate Professor |
| Dept. of Chemistry and Biochemistry |
| University of California San Diego |
| NVIDIA Fellow |
|
http://www.rosswalker.co.uk |
http://www.wmd-lab.org |
| Tel: +1 858 822 0854 | EMail:- ross.rosswalker.co.uk |
---------------------------------------------------------
Note: Electronic Mail is not secure, has no guarantee of delivery, may not be read every day, and should not be used for urgent or sensitive issues.
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Feb 24 2016 - 16:00:03 PST
