Ryco / gmx.net wrote:

> Hi!
> 
> Seems like I am not the only one having problems with Instiki. I got a
> message off list, saying they abandon Instiki because of too many bugs to
> work around. *Sigh* This is going to be a lot of work.
> 
> I am a little bit disappointed that I didn't get any answer from DHH at all
> (David, are you reading me?). At least something like 'Sorry, I don't have
> the time to support Instiki at the moment because work on Rails takes too
> much time' would have been polite. 
> 
> To quote Daniel Berger from his 'Preparing Ruby Packages for Public
> Consumption' page at
> http://ruby-miscutils.sourceforge.net/preparing_ruby_packages.html :
> 
> 'Seriously, if you donÃÕ plan on responding to feedback, or donÃÕ like the
> notion of answering questions about your code, DO NOT PUBLISH.  If you
> arenÃÕ willing to maintain your module for at least a year, DO NOT PUBLISH.'

I sympathize with your problems; I've had issues with various free, OSS 
packages, and do not always get the help I would prefer.

But, being myself a provider of free software, I well understand how one 
can get too distracted by too many tasks, such that some begin to suffer.

I disagree that people should refrain from releasing code unless they 
have real plans to provide support. That sets too high a bar for many 
people who might otherwise have good, practical (even if flawed) code to 
offer.

Ideally, when code is released, there should at least be a good-faith 
assessment of what sort of support can be expected.  I've released code 
with the README essentially saying, "Do not expect *any* support, 
patches, upgrades, or fixes.  Send suggestions or patches, but do not 
expect an answer.  Really. I'll try, but no promises."

Then why release the code?  Because code in public, whatever the 
quality, is more valuable than code in private.

The issue has more to do with managing expectations than making promises 
you can't keep.

James

raise "Keep in mind that it's all a gift." if horse.mouth.look?