I do think to be an successful open source project we need more developers and more features. Activity is very important, it is kind of the lifeblood. Yes, a project will generally become more stable and slow in time as it nears "perfection" (or at least, a local optimum) but the current source is *far* from that.

Yes -- bugs and scalability issues need to be addressed, but this will be a lot easier if some underlying problems are solved. And if we ignore the end users, they may run away and it becomes a pointless exercise.

Taking the "long view" this includes build system, handling of threads/concurrency, modularization, pluggable DB and storage back-ends, separating the system into multiple "locked-down" processes, and so on.  This can all be done while remaining P2P-compatible for as long as possible (we have versioning, don't we?).

My proposal with multiple branches was about looking at the long view as well as the immediate firefighting.  Yes, some changes might be riskier than others, but we can't just cargo-cult Satoshi's work forever... so with multiple branches, people can choose whether they have the balls to try something newer or just want to run the older version with the issues they know and love.

It's better to be open. Look at Open Office, it only started to un-stagnate when it was forked out of Oracle's stranglehold. People want to work on these things, so why not?

Until this is addressed, developers will prefer creating their own fork or even alternative client. After this UI stuff is handled I'll probably join up with one of them.

> In this particular case, I said I was mildly against it-- if you want
> me to switch to supporting it, then reassure me you're willing to do
> ALL the work to make it happen.  Send me a list of wiki pages you'll
> edit to document the change and tell me that you'll be around to help
> people rewrite their backup scripts.

IMO this should have been your first reply, instead of first discourgaging me from doing it. Just make a list of what needs to be done.

But I won't bother anymore... Let's just keep lumping everything in one executable. It's the Satoshi way.

On Wed, Aug 10, 2011 at 7:32 PM, Andy Parkins <andyparkins@gmail.com> wrote:
> Of course, nothing forces existing developers to accept these new features;
> but the incredibly negative attitude on display when any new feature is
> suggested is not the way to grow a community.  The correct way is a
> mentoring attitude -- offering opinions on how a new developer can get their
> idea in rather than telling them why it will never happen.

Exactly. My gripe is more about the negative attitude then anything else.  The focus is always on the negative sides of every proposal, a bit of a climate of fear.

I've had an employer that worked in the same way. Eternally hammering on "stability" the codebase, hiring 100's of extra developers, all firefighting and fixing immediate issues with "priority", the code became a minefield. Even with 8 hours of testcases, the overall structure of the code caused so many issues that customers feared every new release more. A classic negative feedback loop.

I understand where it is coming from, many people just come and dump their "ideas" and never implement a line of code. But if people are actually proposing to implement something, or implemented it, they should IMO be given the benefit of the doubt. Not all outside ideas are bad.

JS