Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1QrUEq-0005Lu-EB for bitcoin-development@lists.sourceforge.net; Thu, 11 Aug 2011 12:19:52 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.213.175 as permitted sender) client-ip=209.85.213.175; envelope-from=witchspace81@gmail.com; helo=mail-yx0-f175.google.com; Received: from mail-yx0-f175.google.com ([209.85.213.175]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.76) id 1QrUEp-0008RX-Gi for bitcoin-development@lists.sourceforge.net; Thu, 11 Aug 2011 12:19:52 +0000 Received: by yxi19 with SMTP id 19so1588069yxi.34 for ; Thu, 11 Aug 2011 05:19:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.31.13 with SMTP id e13mr535185ybe.174.1313065185977; Thu, 11 Aug 2011 05:19:45 -0700 (PDT) Received: by 10.150.52.5 with HTTP; Thu, 11 Aug 2011 05:19:45 -0700 (PDT) In-Reply-To: References: <1312971289.3253.6.camel@BMThinkPad.lan.bluematt.me> <20110810104316.GA30749@ulyssis.org> Date: Thu, 11 Aug 2011 12:19:45 +0000 Message-ID: From: John Smith To: Gavin Andresen Content-Type: multipart/alternative; boundary=000e0cd35788fa274a04aa39cf2c X-Spam-Score: 0.1 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (witchspace81[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.1 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (witchspace81[at]gmail.com) 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.6 AWL AWL: From: address is in the auto white-list X-Headers-End: 1QrUEp-0008RX-Gi Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Change to multiple executables? X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 12:19:52 -0000 --000e0cd35788fa274a04aa39cf2c Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 10, 2011 at 6:41 PM, Gavin Andresen wrote: > > Well, to be honest I don't think more developers adding new features > are needed right now-- I think the project's critical needs are more > people testing and helping to fix bugs and scalability issues. > 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 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 --000e0cd35788fa274a04aa39cf2c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 10, 2011 at 6:41 PM, Gavin Andre= sen <gavina= ndresen@gmail.com> wrote:

Well, to be honest I don't think more developers adding new featu= res
are needed right now-- I think the project's critical needs are more people testing and helping to fix bugs and scalability issues.

I do think to be an successful open source project we need mor= e developers and more features. Activity is very important, it is kind of t= he 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 th= e end users, they may run away and it becomes a pointless exercise.

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

My proposal with multiple branches was about looking at the long view a= s well as the immediate firefighting.=A0 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 issue= s 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 t= o work on these things, so why not?

Until this is addressed, develop= ers will prefer creating their own fork or even alternative client. After t= his 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<= br> > me to switch to supporting it, then reassure me you're willing to = do
> ALL the work to make it happen. =A0Send me a list of wiki pages you= 9;ll
> edit to document the change and tell me that you'll be around to h= elp
> people rewrite their backup scripts.

IMO this should have been your first reply, instead of first discourgag= ing 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 on= e 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 feat= ures;
> but the incredibly negative attitude on display when any new feature i= s
> suggested is not the way to grow a community. =A0The correct way is a<= br>> 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 els= e.=A0 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 hammeri= ng on "stability" the codebase, hiring 100's of extra developers, = all=20 firefighting and fixing immediate issues with "priority", the cod= e=20 became a minefield. Even with 8 hours of testcases, the overall=20 structure of the code caused so many issues that customers feared every=20 new release more. A classic negative feedback loop.

I understand whe= re 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 ben= efit of the doubt. Not all outside ideas are bad.

JS

--000e0cd35788fa274a04aa39cf2c--