On Sun, 20 Jul 2008 20:17:52 -0300, Nicolas Alvarez wrote:

> Jim Henderson wrote:
>> Unless the publisher explicitly grants permission for that type of
>> distribution as a one-off.
> 
> That can't be easily done with software with lots of authors. If I
> contribute code to the Linux kernel under the GPL, can Linus Torvalds
> give an exception to a specific person to redistribute the kernel under
> different terms, including that tiny bit of code I contributed?

That's why I said "publisher" rather than "author". :-)

Jim

Post a reply to this message

Nicolas George wrote:
> Thorsten Froehlich  wrote in message <487f760c$1@news.povray.org>:
>> I do not recall the POV-Ray 3.6 source code having vanished from Earth any 
>> time in the past since its initial release.
> 
> The 3.7 source code, on the other hand, was not there. You know it
> perfectly, as you know that this is what I am talking about.

It does not matter for a willing contributor.

>>> Do you not agree that, in order to attract contributors, you need to make
>>> them feel welcome?
>> Yes, I agree that every team member needs to greet all contributors with 
>> flowers personally.
> 
> That is not what I am talking about.
> 
> If you happen to be wondering why there are so little contributions to
> POV-Ray, just look in a mirror: that is precisely your attitude that makes
> them go away.

My attitude? - In how many open source projects will the following attitude 
ever work: I am new to the project, so first I tell the existing developers 
all they do wrong. Then I claim that I am the over-expert in some field, 
i.e. parallel programming, and hence when I come I expect all developers to 
drop everything they are doing to support my major changes to their program.

On the other hand, in how may open source projects has the following 
attitude ever worked: I am a developer new to your project. I saw you have a 
few open bugs. Here are small fixes for those bugs. Further, I have some 
suggestions for more substantial improvements, would you like to hear them?

> Please note that I am not accusing you: you have a total right not to want
> contributors. But in that case, be coherent: do not pretend you want them,
> and do not pretend your project is open.

I am not pretending! I am just saying what you would hear in every other 
open source project: We expect developer to first show their ability before 
we would like to invite them as regular contributors. With such an 
invitation come certain rights, i.e. repository write access.

> If, on the other hand, you actually want contributors, then you should as
> soon as possible set up a public developers mailing-list and current source
> code repository. And then be patient, as you have quite a lot of bad
> reputation that needs to be forgotten.

Just because we don't want contributors like those who contributed to the 
Debian OpenSSL "fix" does not mean we don't want contributors. But fact is 
that ten monkey on typewriter contributors are not worth half as much as a 
single competent contributor who actually knows what he/she is doing.

If that makes us having a "bad reputation" in your mind, well, then what, 
for example, reputation does Debian have left about the quality of its 
contributors?

With POV-Ray we are talking about a ray-tracer, and several of the 
algorithms require (US) graduate-level math to just understand heir basics. 
Add the ability to program in C++ on an advanced level, and soon the number 
of potential contributors approaches one to zero :-(

	Thorsten

Post a reply to this message

>     Actually, it used to have a reasonably active community of
> contributors (just before 3.5 was released). They didn't contribute
> directly to the core, but instead they contributed to MegaPov. That
> worked because (here we find your two points):
> ~ - Most discussion took place openly on the newsgroups here;
> ~ - Nathan Kopp (who maintained MegaPov at the time) released new
> versions very frequently (including the source).
> 
>     When 3.5 came out, all this activity petered out. Among the
> possible reasons are:
> ~ - Nathan got included in the core team and had less time to keep
> releasing MegaPov on the same rythm;

More like: Nathan graduated from university and moved to another city, got a 
full-time job and enjoys a real-life ;-)

> ~ - The 3.5 code was quite different from the 3.1 code (on which
> MegaPov and all community development were based and which was
> pretty old at the time). When 3.5 came out, it required a
> significant investment to port the patches to the new code base and
> most contributors didn't want to spend that time re-doing something
> they had already done just to have to do it again when the next
> version came out (which is one reason why I never ported my
> contributions to the new code base and simply moved to other projects).

More like: The code in 3.5 was not substantially different from 3.1 The 
problem was that the POV-Team had to spend months over months getting the 
MegaPOV patches into a full working order. As it turned out much to the 
POV-Team's disappointment, most of them worked only 95% of the time and they 
were not production quality. Yet, some problems could not be fixed in finite 
time, i.e. that is why sphere-sweeps sing splines have bounding problems. 
The bounding algorithm in the original implementation never worked right. 
BTW, this bug is relatively well known, yet no external developer ever fixed 
it :-(

	Thorsten

Post a reply to this message

Chris Cason wrote:
> Nicolas George wrote:
>> Do you not agree that, in order to attract contributors, you need to make
>> them feel welcome?
> 
> Please note that Thorsten speaks for himself when posting here (unless he
> explicitly says otherwise). As do I, for that matter.

Indeed, but I prefer others not apologizing for me if there is nothing to 
apologize for.

> So, this post is on behalf of the project: developers are welcome to
> contribute. We can't always take contributions (the megapov days taught us
> that) but anyone wanting to improve the program in a meaningful way is
> welcome here.

That is exactly what I am saying as well.

	Thorsten

Post a reply to this message

Thorsten Froehlich  wrote in message <48843f8c@news.povray.org>:
>							      I saw you have a 
> few open bugs. Here are small fixes for those bugs.

Stop here. The source code was not available. The conversation is therefore:
"I saw you have a few open bugs. I can not fix them without the source code.
I will go and see if I can help someone else."

>		       We expect developer to first show their ability before 
> we would like to invite them as regular contributors.

And for that, they need access to the source code to propose patches. The
current source code, not an obsolete one.

> With POV-Ray we are talking about a ray-tracer, and several of the 
> algorithms require (US) graduate-level math to just understand heir basics. 
> Add the ability to program in C++ on an advanced level, and soon the number 
> of potential contributors approaches one to zero :-(

And sadly, the lack of access to the source code made him go away two years
ago.

(And by the way, POV-Ray is not just a ray-tacer, there would also be some
useful work in all the system part.)

Post a reply to this message

Nicolas George wrote:
> Thorsten Froehlich  wrote in message <48843f8c@news.povray.org>:
>> 							      I saw you have a 
>> few open bugs. Here are small fixes for those bugs.
> 
> Stop here. The source code was not available. The conversation is therefore:
> "I saw you have a few open bugs. I can not fix them without the source code.
> I will go and see if I can help someone else."
<snip>
> And sadly, the lack of access to the source code made him go away two years
> ago.

I provided one example of a bug existing since 3.5. I can add several more 
to that list, all publicly known and for none it is difficult to check that 
they still exist in 3.7. For none was a fix ever contributed in *seven* years!

	Thorsten

Post a reply to this message

rafal wrote:
> Thorsten Froehlich wrote:
> 
>> Yes, I agree that every team member needs to greet all contributors with
>> flowers personally.
>> Thorsten
> 
> What if given developer has an allergy to particular flower?

Hmm, the developer will be greeted with chocolate ;-)

	Thorsten

Post a reply to this message

Thorsten Froehlich  wrote in message <4884b36d@news.povray.org>:
> I provided one example of a bug existing since 3.5. I can add several more 
> to that list, all publicly known and for none it is difficult to check that 
> they still exist in 3.7. For none was a fix ever contributed in *seven* years!

That only proves my point: the lack of welcome to contributions made
everyone go away.

Post a reply to this message

Nicolas George wrote:
> Thorsten Froehlich  wrote in message <4884b36d@news.povray.org>:
>> I provided one example of a bug existing since 3.5. I can add several more 
>> to that list, all publicly known and for none it is difficult to check that 
>> they still exist in 3.7. For none was a fix ever contributed in *seven* years!
> 
> That only proves my point: the lack of welcome to contributions made
> everyone go away.

ROFL

	Thorsten

Post a reply to this message

> [...]
> ~ - The 3.5 code was quite different from the 3.1 code (on which
> MegaPov and all community development were based and which was
> pretty old at the time). When 3.5 came out, it required a
> significant investment to port the patches to the new code base and
> most contributors didn't want to spend that time re-doing something
> they had already done just to have to do it again when the next
> version came out (which is one reason why I never ported my
> contributions to the new code base and simply moved to other projects).


Actually the reasons for the MegaPOV development having stopped more or 
less is due to a multitude of reasons - the nature of official POV-Ray 
development after 3.1 is only one of them.  It made continuous 
development of patches more difficult but actually 3.5 and 3.6 both 
greatly simplified managing the project (since both times various 
important changes were integrated or made obsolete by the official 
changes).  Adapting your patches to the changes in the base system for 
example would have been no serious problem but it was not done (i 
considered it several times but always got other priorities in the way).

Here a list of reasons that are from my perspective the most significant 

factors

- change of priorities of several active contributors: Nathan, 
Wlodzimierz and myself.
- lack of interest and participation of both developers and 
non-developers.  We did not receive much feedback on the patches, 
epspecially in the form of active users reporting their experiences and 
contributing sample scenes, tutorials etc.  Note this is not meant to 
sound disappointed - there are multiple reasons for this like the change 

of the software landscape in 3d-CG, the change of mentality in the net 
in general and the focus of the patches that were actively developed.  I 

don't know if licensing actually plays a significant role here but i 
doubt it.
- limitations of the currect internal design of POV-Ray for implementing 

interesting features (this is mostly still the case for 3.7 BTW).
- significant changes in some of the primary computer platforms MegaPOV 
is used on.  This was of course the Apple switch to Intel hardware but 
also the developments on the Windows platform that turned away many 
developers (in the end we had no possibility to build a Windows 
executable with good performance among the core developers any more).

Note much of the actual patch development has been done by individuals 
without much discussion with others - neither private nor public.  This 
has been the case both in the old MegaPOV 0.x as well as afterwards.

-- Christoph

Post a reply to this message