1. "the FOSS community is largely anemic in the bio world" I'm shocked by that. I think of the bio world as having a lot of FOSS software. With BOSC it even ha

1. "the FOSS community is largely anemic in the bio world" I'm shocked by that. I think of the bio world as having a lot of FOSS software. With BOSC it even has its own yearly (satellite) conference. By comparison, I work in chemical informatics, and think that FOSS availability in chemistry is rather less than biology. I've blamed money - chemists have a longer history of making money from their research than biologists. Which research field do you think has a robust FOSS community and where there are also for-profit companies developing commercial in the same field? 2. "You need to have your own programmer, and a good sysadmin". You say that myth is true, while Pachter thinks it's false. Your disagreement is really more one of team size. Pachter's myth concerns "a large team." You have a team made of a handful of people. That is, Pachter wrote: "I agree with James Taylor, who ... stated that ”... Scientific software is often developed by one or a handful of people.”", which is what you have. I can agree that it's not clear from the text that the myth concerns, having ~6 or more people in the team. 3. Could you explain why your explanation makes the myth true? Pachter gave the example of the UCSC genome browser. From its web site, "The Genome Browser, Blat, and liftOver source are freely downloadable for academic, noncommercial, and personal use. For information on commercial licensing, see the Genome Browser and Blat licensing requirements." Were you working in a for-profit genetics lab when you realized that FOSS was so important? Otherwise, how would a restriction like the UCSC one have affected you? 4. I actually think the FOSS vs. licensing cost are somewhat orthogonal issues. I distribute my software under the MIT license, but only to those people who pay me about US $25,000. This is something the FSF encourages, as a way to bring revenue to a project. However, it only works because I'm not trying to establish some sort of "community" but prefer a vendor/customer relationship. BTW, I think points #1, #2, #3, and #5 can be recast as "you need to build a community around your project." I think that's a myth in its own right.