Re: OpenEuphoria's Strategy
- Posted by jimcbrown (admin) Feb 07, 2015
- 2386 views
I wish i could remain part of my "babies", if any more work is "required" on them (such as the multiserver version of irc.e, which works except it is midway thru a irc.e-irc_client.exw split and not suitable for release). I am pretty sure i'll be kicked out of them.
Kat
I have lots of finished and unfinished projects sitting on my hard disc that might never see the light of day. The trick is to try to create start things that will be small enough to finish.
Agreed. I think another part of it is motivation. I once chatted with a fellow - Paul Brook of Cygnus Solutions - who said something along the lines of, "If it's not going to be accepted and committed, I see no point in writing the first line of code for it."
Obviously, I disagree - I think people should code for the joy of coding, not for the purpose of getting stuff submitted. (At least in Mr. Brook's case, the rationale made a little more sense - he got paid to code on FOSS. But AFAIK that's not the case for anyone here.)
It's easy to get demotivated to finish a project you've started. (E.g. "it'll take several months before anyone has time to review a patch of that size" -> patch never gets written.) It's even worse if you want to be the one person who exclusively has access to and approves changes for the part of the code that you worked on and submitted to another project. That almost never happens .. since that's simply not how FOSS works.
Edit: I imagine that some people, trying and failing to get their code submitted along their standards (instead of the standards of the project that they are submitting their code to), may feel as they have been forced from finishing their coding. However, I think this is just another form of getting demotivated to finished - it's not like the project team broke into a coder's house and destroyed the computers there, or tied the coder to a chair until the coder promised not to finish the code. The coder can certainly finish what the coder started. In more extreme cases, coders can prove that they are right and the project team is wrong simply by forking the project and doing things their way.
