I know I'll never be able to convince you but here I go anyway...
It's good that you know you are fighting a losing battle. It puts things in perspective. ; - 0
Define complete? If the code can be successfully compiled to an executable then I'd say it's complete enough. People doing a checkout or just browsing the code will know it's a work in progress and won't expect it to be perfect.
"Successfully compiled to an executable" is a terrible standard. Nothing can probably ever be perfect but no code should be shared/checked into a library without a reasonable amount of review and testing. (In my case I use a lot of testing to get around the fact that I don't have peer reviews until an initial "good enough" version is shared.)
Why not? Don't take this the wrong way but
a very interesting talk by a couple of guys you might know is starting to feel relevant here. :D
I think they know something about software engineering. But this isn't a matter of proving I am a genius or not. The only opinion that matters there is my wife's opinion. And she is firmly in the "no" camp.
But seriously, as more of a firmware engineer I am not a big fan of "throw it against the wall and see if it sticks". Especially when programming in what is essentially an embedded environment. I need the base code to be as reliable as possible so that other people do not have to struggle with it. It was flakiness with NTCPDRV that led me to write my own entire stack and applications.
Yes, but it is possible. Besides, maybe there are other bugs in the code that someone could find.
I have no problem with people finding bugs; you have found your share. But I do take responsibility for getting rid of the obvious ones, and for finding the devilish ones.
If the code is easily accessible (with a browser) then it will attract interest from people. If they see something they think they can improve then they will contribute (with new features, bugfixes, optimizations, whatever). If you only release full featured, bug free, optimized and polished code in a zip file (in other words, your finished programs) that's never going to happen.
I'm not sure I agree with most of these points. A browseable repository might make things easier for the casual user, but I'm not terribly interested in casual users. I think there are plenty of problems in the current code, and plenty of features still left to implement. The distribution of the source code is not a real impediment - people have been working with tarballs and other "bunch of files" distribution formats since the beginning of time.
Maybe people have less incentive to work on things that are good enough; I can't argue that. But if you use IRCjr as an example, the first source code was released in 2011. In the two years since the code was first released I added the mIRC color codes, additional /ctcp commands, fixed bugs with some servers, added standard IRC attributes such as bold, italics, underlining, added 132 column support, added the PASS command, added config file parameters for handling the various quit and nick messages, and did some refactoring to clean things up and reduce memory footprint. I did these things because they bothered me and nobody else was interested ...
You in particular have had a history of working on the performance and picking holes in what the compiler generates. But up until about a week ago, you were the only other person who got their hands dirty. Last week somebody gave me code for handling additional code pages. Their barrier to entry wasn't the ZIP file with the source code; it was learning how to use Watcom. And I think they were a lot happier getting their hands dirty knowing that the foundation they were working with was solid.
As for the mystery Mike C bug, I think I found it tonight. It was a classic uninitialized pointer, which worked great if the pointer was NULL but failed miserably if it picked up previously dirtied memory. I've added a lot of consistency checking code and I'm going to add some more so that the next time this happens there will hopefully be less flailing.
And don't worry. After I release an initial version there will still be plenty of other things for people to do. And yes, I will get the SVN repository enabled at some point. I'm never going to check in my works-in-progress, but it is a nice way to get bug fixes out there faster.
