From: Caleb James DeLisle <calebdelisle@lavabit•com>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Seeking advice: Encouraging bug-fixing over new features
Date: Thu, 28 Jul 2011 11:37:21 -0400 [thread overview]
Message-ID: <4E318231.9020707@lavabit.com> (raw)
In-Reply-To: <CA+8xBpcKNrGFKkN4mAW9E_s9Ph1=Qh9DNWryihDmD90HWMWF3Q@mail.gmail.com>
Bitcoin seems to have a relatively unique problem, there is a perception that there are early adopters who still have large stashes of btc.
Not that this is wrong, they knew a good thing early, the problem is that it is hard for someone (me) to justify volunteering work on a codebase which will directly benefit other people even if they do nothing.
From my brief observation it appears that the developers now are split between early adopters who are working on their investment, ambitious people who are working on alt clients to satisfy certain requirements for their own projects and hobby developers donating code to alt chain clients because chains which have not taken off don't benefit anyone yet.
As far as trying to bring these people together, I don't have any silver bullet answers but I think there needs to be some kind of sponsorship of developers. I2P uses bounties but they are indeed a small community, I can see bounties going very wrong but I suppose it doesn't hurt to experiment. I think grants for active developers make more sense, then we only need someone to decide who is active enough.
Also moving in the direction of seperating bitcoin the program from Bitcoin the blockchain and accepting patches for merged mining and alt chain stuff which doesn't directly benefit Bitcoin would help decrease the "people are making money off of my back" feeling that (IMO) stands in the way of new developers.
Caleb
On 07/27/2011 08:15 PM, Jeff Garzik wrote:
> Linux kernel has not solved this problem; developers simply want to
> work on interesting stuff, rather than debug, I think.
>
> The best Linus has done so far it making certain periods of time
> bugfix-only, refusing to take new feature pushes during the stability
> period. If there are critical bugs, refusing to release the kernel
> until a developer fixes the regressions they added.
>
> Linux is large enough, though, that the ecosystem has grown a support
> network, where companies pay for support (one big way my employer
> stays in business), which includes bug fixes. So the paid support
> orgs, like Red Hat, wind up going a lot of grunt work fixing because
> they are the closest contact to actual users in the field encountering
> problems with the Wonderful New Features bestowed upon them by
> developers.
>
> "drop and run" coding is a term for developers who appear, commit a
> new feature, and then disappear without addressing bug reports or
> other feedback regarding their contribution.
>
next prev parent reply other threads:[~2011-07-28 15:30 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-27 1:31 Gavin Andresen
2011-07-27 6:40 ` John Smith
2011-07-27 11:14 ` Joel Joonatan Kaartinen
2011-07-27 14:20 ` John Smith
2011-07-27 14:28 ` Luke-Jr
2011-07-27 14:42 ` Joel Joonatan Kaartinen
2011-07-27 14:53 ` John Smith
2011-07-27 16:02 ` Douglas Huff
2011-07-27 16:07 ` Rick Wesson
2011-07-27 16:47 ` Matt Corallo
2011-07-27 17:11 ` John Smith
2011-07-27 17:15 ` Joel Joonatan Kaartinen
2011-07-27 22:45 ` Gavin Andresen
2011-07-27 22:54 ` Joel Joonatan Kaartinen
2011-07-27 23:07 ` Matt Corallo
2011-07-28 6:31 ` John Smith
2011-07-28 0:15 ` Jeff Garzik
2011-07-28 15:37 ` Caleb James DeLisle [this message]
[not found] ` <1311811317.72375.YahooMailNeo@web121005.mail.ne1.yahoo.com>
2011-07-28 0:02 ` [Bitcoin-development] Fw: " Amir Taaki
2011-07-30 11:49 ` [Bitcoin-development] " Mike Hearn
2011-07-30 14:06 ` Rick Wesson
2011-07-30 14:07 ` Matt Corallo
2011-08-03 1:41 ` David Schwartz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E318231.9020707@lavabit.com \
--to=calebdelisle@lavabit$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox