On 18 December 2010 04:40, Julian Leviston <[email protected]> wrote:
> Usually, when I'm working on a development of any kind, I don't release my
> half-baked ideas.
It's a mistake!
> Firstly, it means that when I *do* release
> what I have to share, it's at a level that I'm prepared for people to
> comment on - it's in a state that I'd consider developed enough that it can
> be understood... and secondly, it stops people from "muddying up" my ideas.
This is a matter of self-discipline: don't read feedback until you're
ready. Meanwhile, don't presume to know what people will or won't get
out of your ideas.
> In exactly the same way, I won't send this email that I'm writing until
> I feel it's finished.
That's not the same at all. Not sending the email until it finishes is
like not committing code until it compiles and passes tests.
> - I don't have time to explain myself to people who aren't working at the
> same level that I'm working.
I'm not asking for explanation. People who aren't working at the same
level as you can try to understand it, or give up; the audience for
pre-alpha stuff will largely be self-selecting. But it is a critical
audience to engage as early as possible, so that you have plenty of
people who actually care about your project when it does release.
> To do so before it's ready would be irresponsible to both the
> project and its intentions. It would water it down. When you're dealing with
> powerful ideas, you really don't want them to be watered down. (ie
> misunderstood).
Assuming that half-baked code and documentation will be misunderstood
(any more than completed stuff). But really this is just a combination
of voodoo (what are these problematic "powerful ideas"?) and
condescension.
There are two main reasons to keep things to yourself until release:
1. You prefer to release only polished artefacts. This is just egotistical.
2. You want to exploit your knowledge in secret. That shouldn't apply
to a publically-funded project.
(There's also 3. You don't care about getting your ideas out there;
but that clearly doesn't apply here.)
In short, this is research done the old-style way with which the
researchers are comfortable, and I certainly hope that interesting
stuff comes out of it and is widely disseminated and used, but VPRI
are doing themselves few favours, apparently not recognising the value
of the attention they've gotten even from the few small concessions
that they have made (one or two of them appearing on the mailing list,
for example; kudos to them for that). Of course, you need substance as
well as buzz, and even both together don't guarantee success; but the
trouble is that the "do it in a closed room and then release when
ready" mentality tends to leak over into the eventual release ("what?
we released the code on an ftp site and no-one took any notice?
ungrateful wretches!"), and does not augur well for eventual success.
That success is something I'm as desperate to see as anyone.
--
http://rrt.sc3d.org
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
