On 20 December 2010 13:42, Brian Gilman <brian.gil...@gmail.com> wrote: > > Just because you believe that "Release early, release often" is the best > release strategy, doesn't mean that everyone at VPRI does.
I really don't understand comments like this. Fairly obviously I know that not everyone at VPRI believes that, otherwise they would be doing it, and I wouldn't be trying to convince them to do it. Are you saying that I shouldn't be trying to change people's minds? (I think you're just saying my attempt is a poor one.) > I work in video game development, and it's a pretty much suicidal strategy >for releasing games. Games are essentially works of art: like a painting or a book. The product of a research project is knowledge, not artefacts. > It's very hard to shake bad first impressions, With a game, you're thinking about showing it to players; dead right. With early-stage research, the audience is not the same as eventual users of the technology. I am not suggesting that the cobbled-together "Frank" be released to public fanfare as a beta of the next big whatever. I am suggesting that it be showed to people interested in that area of research. > I'm skeptical that releasing a bunch of source code for something that has > been described as being on "life-support", announcing to the world that there > has been a revolution in computing, and then > have it not work on a majority of machines, is really the optimal strategy > for success. I don't understand this either. "Release early, release often" is not a strategy; it's a tactic: part of a strategy. I am not claiming it's optimal; I'm claiming that it usually works better than not doing it. > VPRI is getting public funding, but $5 million usd isn't a heck of a lot. To > put that into context, these days, that isn't even enough to make a bad video > game. Academics and game authors have a rather different perspective on $5m. And plenty of excellent games continue to be made for much less; you must be referring to big-budget games which seem to involve digitising lots of physical reality, which is, indeed, labour-intensive. But the amount of public funding is a distraction. The important thing is: > That means that they need to make good use of the resources that they have, > which means keeping focus. Quite so. I am unclear what this has to do with releasing source code. > Which means avoiding distractions, like having to answer a zillion questions > and > unreasonable demands on mailing lists. They don't have to answer any questions, or indeed demands. (Pardon me if I err, but I've noticed no active participant from VPRI in this thread, quite possibly because, as I admit, I've made the same point before, rather more gently, which is perhaps why I'm coming across as "abrasive" this time.) Making your source code repository public isn't a distraction unless you let it be. It does not take extra resources (other than a server and some bandwidth, but that's cheap compared to people), and it actually frees up resources, because interested people can study the code and answer their own questions. At the very least you'll get no more "when are you going to release?" questions on the mailing list. I work and have worked on many free software and open source projects. Most of them are (largely) unfunded; my own work is certainly unpaid. All of them have open development repositories. On none has this ever been an issue. It has only ever reduced labour (typically by attracting new contributors). Now, one may object that most of these projects are merely development, not research, and this is quite true. But one of them, the Glasgow Haskell Compiler, is essentially the product of an ongoing research project, and has been for 15 years. (It started at Glasgow University; it's now at Microsoft Research.) The researchers who lead it get a lot of useful help both from researchers elsewhere, and other contributors; they manage it without being distracted by the obvious, conventional means, namely, having a hierarchy of spaces in which they can choose to meet, from their offices, where obviously they are, when they choose, safe from interruption by anyone who doesn't work there, to conferences, to invitation-only mailing lists, to public mailing lists. Now, I wouldn't say you could attribute the success of the project to this one aspect (Simon Peyton-Jones's nous, charisma and leadership, attracting generations of talented people to work on it would be my vote for Most Important Factor, for starters) but it has certainly helped. -- http://rrt.sc3d.org _______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
