> >> I love MegaPov, but we are being kept waiting in the dark as far as the
> >> actual development schedule is concerned.  If someone on this newsgroup
> >> asks when 3.5 will be released, they will get several "When it's ready"
> >> responses, which are pretty much useless.
> >
> >Well, that *is* the answer...there is no way to predict the final
> >release date. All of the information has been given: it is not yet beta,
> >not all of the additions have been completed, but it will have most of
> >the new features of MegaPOV, the feature list has been frozen, the
> >features just have to be implemented and tested, and nobody knows when
> >it will reach beta, let alone final release.
>
> That's why I dislike the current development model... The only information
> we get about the process is whatever the developers decide to tell us.  I
> would prefer a more open, community-oriented approach (OpenSource,
> basically).  But maybe that's just my preference.

I don't want to propagate long debates like this, bit let me give you some
information from a historical perspective.

The reason I proposed starting a POV-Ray team and using the source for DKBTrace
as a base was exactly because I couldn't keep up with the development on my
own.  There were lots of people who wanted to add new features and extend the
system but couldn't because it was controlled by one individual.  I was just
starting my Master's degree and I felt I wouldn't have time to put into adding
features into a free program and rather than let it die, I handed it over to a
group of developers to allow them to make their enhancements.  It's ironic that
the same situation has occurred in POV-Ray.

If there's anything I learned from my DKBTrace and POV-Ray experience, it's
that integrating all the code. testing it, and putting together a release is as
difficult a job as just writing the code in the first place.  Lots of gotchas
pop in and delay release.  You also get a lot of people breathing down your
neck eager for the next release.  Any time we jumped the gun and released a
package before we were ready, it backfired on us - something critical was
wrong, a fixed version had to be released in a hurry, and users are confused
about what version is right and what version is wrong.  It gave people doubts
about the quality of the program and caused embarrassment on behalf of the
developers. I'm unconvinced that a completely open-sourced approach would
handle these issues well.

Also remember that even though the source is freely available and the program
is free to download and use, it still has a copyright and the POV-Ray team
still owns the intellectual material.  At one time, we seriously considered
allowing various companies to license POV for a charge (keeping it free for
other uses), but the whole idea collapsed because we couldn't agree on how the
profits were to be split. It also caused a riff in the POV-Ray team because it
got into a "my contribution is worth more than your contribution" war.  I can't
image the POV-Ray team tying that again.

I sympathize with the people who feel that the POV-Ray team holds too tightly
onto the reigns of power on POV-Ray.  Remember, though, that they are trying to
set a certain standard on the quality of the package (including docs, examples,
etc) and they are ultimately responsible if things aren't right.  It's easy to
criticize but it's hard to do.  Give them some slack and let them do the work.

As for announcing release dates, there's no point.  Internally, they will
probably have a date they are shooting for.  If they miss that date, though,
they don't want flack from the user community asking "where is it?"  Again
we've been through that before and it's not fun trying to explain slips in
schedules to the user community.  We got into the "we'll announce it once it's
released and no sooner" to try to free our time to do the work rather than
answer questions on why we didn't make our predicted release date.

Enough said.
David Buck
dav### [at] simberoncom

Post a reply to this message