Winboard Forum

There is a BIG problem (IMO) in the chess programming community that should not be! In many post in various threads, programmers complain about no help and/or no feedback about their programs, and if availible, their source code. Especially the second. Some people do not need much help, as they can look at other peoples source and learn enough to bring their engines up to speed. Then there are people like me that even the smallest of ideas are a major struggle. An example of this is the negamax function. When I first got RomiChess up and running, I could not really understand how to manipulate alpha and beta or exactly what they represented, let alone flip and flop them. I do now, but, it took years (from even before I wrote RomiChess). At first I just went on blind faith that It was done right. A smart knowledgeable person could have detected errors in minutes that took me months to discover. It just seems to me that something should be done about this situation.

There may not be a solution, however, I do have at least a suggestion that could be of help. If each author of an open source program that wishes to participate could for a period of time adopt another authors program and make or suggest improvements to their adopted program and the author of the adopted program could do the same for their adopted program, including passing on improvements given to them, then everyone may be able to benifit. Then 'what comes around goes around' could be a good thing! This is a rough idea that I can foresee problems with. However, I think that it is better than no idea at all.

As long as anyone, even unproductive or patchworking people, could access and use open soure code, I am not motivated at all to participate in or support such projects in any form. Exceptions are interfaces, standards or protocols, maybe also application platforms, which are useful to motivate others to write compatible solutions. Chess engines are non customizable end user applications, and thus not ideal targets of open source programming.

A lot of people have very different opinions to that, especially those, who use such code without ever contributing anything of value, or those, who are confusing open source with freeware.

It is doleful, that really active open source workers are sharing such a counterproductive (for chess programmers) license model instead of using a more fair one, based on the division of labor.

Reinhard.

Michael Sherwin wrote:In many post in various threads, programmers complain about no help and/or no feedback about their programs, and if availible, their source code.

This is true, but there is a very easy fix for this. Just keep contacts with other engine authors this problem should go away.

Michael Sherwin wrote:An example of this is the negamax function. When I first got RomiChess up and running, I could not really understand how to manipulate alpha and beta or exactly what they represented, let alone flip and flop them.

Chess programming is hard starting out (atleast it was for me). Nevertheless, I would think that a new engine author who wants to program a chess engine learn the material well before writing code (atleast that was what I expected of myself).

Michael Sherwin wrote:There may not be a solution, however, I do have at least a suggestion that could be of help. If each author of an open source program that wishes to participate could for a period of time adopt another authors program and make or suggest improvements to their adopted program and the author of the adopted program could do the same for their adopted program, including passing on improvements given to them, then everyone may be able to benifit. Then 'what comes around goes around' could be a good thing! This is a rough idea that I can foresee problems with. However, I think that it is better than no idea at all.

Too difficult. Adopting programs is hard work. Stick with the keeping contacts .

I think asking specific questions here and in the CCC forum will eventually result in answers.

If you get no responses, probably your questions are too vague or are not properly understood.