How Open Source Projects Survive Poisonous People

[kgo]

In the longer run, I feel it might boil down to losing one of them (at least from the core team) over this disagreement. It's easy for us to ask them to sort it out peacefully, but sometimes different personality types just don't get along and shouldn't work together.

My worst fear is Gavin would leave because Luke wouldn't. I can't imagine a worse thing happening to Bitcoin right now...
This is n-th call to action by Gavin on forums these days and I think we should listen.

I agree.   If one of them needs to go, there's no doubt in my mind that it should be Luke, absolutely.

Forgive me if I'm wrong, but I was under the impression that all the core devs agreed on BIP 16 initially, but Luke was away at the time.  Upon his return, he disagreed with 16 and all this crap happened as a result.   From my perspective, I don't understand how it was allowed to get this far if only one person from a team of devs disagreed with the proposal.   The majority was in favour of it, therefore it should have been accepted as far as I'm concerned.

Several people in this thread seem to think the sole issue here is differing opinions on BIP 16 vs BIP 17.  The original post cites that as a single example, and not the entire motivation, behind Gavin deciding that Luke was poisonous.  Maybe Gavin was being disingenuous and it really is about this single issue.  If so, call him out on it.  But lets not turn this discussion into a rehash of BIP 16 vs BIP 17.  That's a different discussion.

[kgo]

Just thought I should note that I am intentionally ignoring znort987, CoinHunter, and bitlane, who have demonstrated themselves to be scammers and trolls in the past. If anyone else thinks I need to respond to anything from them, please say so (do note that a good amount of it is outright lies/FUD).

Everything I have referred to has been proven BEYOND the shadow of a doubt, on multiple occasions, so do your best.

Also, had I actually been on your ignore list, how did you know that I was commenting about your actions in the first place ?

That's the way ignores work.  You see a user has posted, but it says that the user has been ignored, so you can't see what they said.  So Luke's post makes sense.

[jimbobway]

The concept of "team" is very important in all organizations and maybe even more so in open source projects.  Team interaction and communication is key.  If a person cannot communicate, lay down his ego, or continually brings up old issues then the whole team breaks down resulting in software paralysis.

Nope. Bitcoin is not a team. It is many teams in a community and part of a process. In project development, relationships aren't always and sometimes shouldn't be cordial.

For instance a regulator and the company they are overseeing, should not have a cordial relationship. Or upstream and downstream if they are functioning properly will have a contentious relationship; I've had some vicious past arguments with downstream before but we remained amicable and professional while disagreeing.
http://fedoraproject.org/wiki/Staying_close_to_upstream_projects#Tips_On_Upstreaming_Patches

Many of the characterisations I see people making all the time comparing bitcoin to a business, a team or charity (to name a few) are unrealistically simple and naive.

Perhaps in open source development relationships aren't always cordial.  (That was why in the video Gavin posted the leads of Subversion were venting.)  I do know that most successful for-profit software development shops where one needs to be physically at work tends, for the most part, to be cordial in environment.  Most people don't want to go to work in a hostile environment and people who don't fit in will quit or get fired.

If I were lead I would want to produce an open source environment that is as cordial as possible, even though that may never happen.

[2_Thumbs_Up]

Gavin, I think you should separate 2 issues. This is not about an Opensource Project called "Official Bitcoin Client". The client is not really important - it's a reference implementation, nothing more. This is really about the *standard* any client must implement.

The movie you linked to is only about how an Opensource Project should deal with, what they call, "poisonous" people. But this simply is not about code. Perfectionism can be an impediment when it comes to code, but when it comes to a standard, perfectionism is essential.

I can't judge the BIPs for their merit, but it seems to me that this new standard did not have sufficient time to mature yet. Maybe the current quarrel should be looked at as a constructive effort to enhance a standard that is, in my humble understanding, revolutionary. You must get it right the first time. Please take your time!

Seriously, this post needs more love. As a bitcoin saver the way this protocol change has been tried to be rushed through is far more worrying than some potential technical bugs with the implementation. If this will become the precedent for how future protocol changes will be handled then I'm out of bitcoin. Satoshis way of a 2 year plan seem far more conservative and proper.

[interlagos]

Gavin, I think you should separate 2 issues. This is not about an Opensource Project called "Official Bitcoin Client". The client is not really important - it's a reference implementation, nothing more. This is really about the *standard* any client must implement.

The movie you linked to is only about how an Opensource Project should deal with, what they call, "poisonous" people. But this simply is not about code. Perfectionism can be an impediment when it comes to code, but when it comes to a standard, perfectionism is essential.

I can't judge the BIPs for their merit, but it seems to me that this new standard did not have sufficient time to mature yet. Maybe the current quarrel should be looked at as a constructive effort to enhance a standard that is, in my humble understanding, revolutionary. You must get it right the first time. Please take your time!

Seriously, this post needs more love. As a bitcoin saver the way this protocol change has been tried to be rushed through is far more worrying than some potential technical bugs with the implementation. If this will become the precedent for how future protocol changes will be handled then I'm out of bitcoin. Satoshis way of a 2 year plan seem far more conservative and proper.

Regarding the time frame, it could be that there are already other things in the pipeline related to scalability of the blockchain that would need to be addressed in a timely manner and that depend on how multisig is implemented.

Imagine another bitcoin boom by this summer and the amount of transactions increases tenfold. You can't really wait another 2 years with this, maybe not even another 3 months. I think the next big thing to focus on is scalability and we need to have multisig settled down right about now.

[Andrew Vorobyov]

"Imagine another bitcoin boom by this summer"
my wet dream

[Bitcoin Oz]

Its dangerous to let Luke-Jr have anything to do with code for bitcoin. His recent behaviour of sending a DMCA notice to an alt coin dev shows what he really believes. Which is sending men with guns to your house if you do something he doesnt like.

This sort of action makes it too risky to allow him access to insert code in bitcoin that will allow him to take it down or worse threaten companies. Using your mining pool to bully alt chain devs then if hat doesnt work using the gun in the room is enough to disqualify him imo.
'

[bittenbob]

Luke,

I have yet to see you address this issue Gavin has pointed out:

For context: makomk is the creator of CoiledCoin, a bitcoin alternative:
  https://bitcointalk.org/index.php?topic=56675

And RE: creating bots:  I created a BIP-17-stealing bot because it was really easy (took about 10 minutes of hacking).  A BIP-16-stealing bot would be a lot harder (because it would have to 'lie in wait' until the sender was redeeming the coins, and then race to relay/mine a 'stealing' version of the transaction before the rest of the network mined the original).

Gavin,

I see that you just found a bug in your code the other day and fixed it:

You know how I say "I make mistakes, don't trust me" ...

A bug in my code is dropping transaction fees from the block reward. Simple to fix, and obvious in hindsight; I will be personally reimbursing everybody who got bit by this bug by finding the blocks affected by this, figuring out what transaction fees the creators SHOULD have received, and sending that number of bitcoins to the block-award address.

Backports and the main git HEAD tree have been patched with the fix.

On a higher level:

There is obviously not going to be 50+% blockchain support for BIP 16 on Tuesday; I'm going to start conversations on how to move forward.

And there has obviously not been enough testing of the BIP 16 code. Getting people to thoroughly test things BEFORE code makes it into the main tree has been a chronic problem, I'd appreciate ideas on how to avoid this kind of annoying, time-wasting "it's ready"/"oops, found a bug"/"it's fixed"/"wait, no, somebody found another bug" thing in the future. I've been unsuccessful finding the kind of QA (quality assurance) person who can both do the QA and do the fundraising necessary so they get paid.

I am sure you are both great programmers but it is reasons like this why I think further testing is needed before we try to push this any further on the main block chain. It is for this reason I have chosen to move back to Deepbit for mining, since they want to delay any hasty implementation. Clearly no one has a consensus among the Bitcoin community as to which one (or neither) to use but I believe since Satoshi essentially anointed Gavin as the head developer I think he should have final say. I would hate to see him leave the project over this.

Is it possible for both of you to scrap your individual BIP's and work together on a single common one? This will take some concessions on both your parts but I think the end result would be a much better and more secure Bitcoin project.

Let me take the time to point out the root words of community. Common Unity = community. There has to be a civilized way to work this out.

[[Tycho]]

I am trusting that Tycho will wait for us to all calm down, eventually review this thread, determine that the consensus is clearly with Gavin, and run with it.

Looks like I have to remind one of my points:

• I don't think that there is any chance of BIP17 winning because it's not supported by any major force besides Eligius (sorry, luke)

I like the fact that it doesn't uses magic cases and serialized form, but it may have drawbacks too. Also, I expect most people to be disappointed if I choose BIP17.
So I'll repeat: I don't think that there is any serious competition between BIP16 and BIP17. The only question is WHEN BIP16 will be adopted (if no other proposals appear soon).

I would immediately support any plain multisig scheme or sane long-address multisig TX proposal as possible first-stage on our way to P2SH to allow people play with it and get more time for preparing P2SH deployment.

[Luke-Jr]

Luke,

I have yet to see you address this issue Gavin has pointed out:

For context: makomk is the creator of CoiledCoin, a bitcoin alternative:
  https://bitcointalk.org/index.php?topic=56675

And RE: creating bots:  I created a BIP-17-stealing bot because it was really easy (took about 10 minutes of hacking).  A BIP-16-stealing bot would be a lot harder (because it would have to 'lie in wait' until the sender was redeeming the coins, and then race to relay/mine a 'stealing' version of the transaction before the rest of the network mined the original).

The only reason he could steal the transactions was because the BIP was not active. If it was active, he could not have done it. After he did it, it was a simple matter of enabling the BIP to bypass it. I disagree that a BIP-16-stealing bot would be a lot harder: we already have a "hub mode" patch to connect to a lot of nodes, and all one needs to do is modify the output address for every transaction they relay. I could probably finish it in under 10 minutes, but honestly I have better things to do, and giving people trying to test BIP 16 a hard time isn't my idea of productive since (for both BIPs) it isn't a practical real-world attack.

Is it possible for both of you to scrap your individual BIP's and work together on a single common one? This will take some concessions on both your parts but I think the end result would be a much better and more secure Bitcoin project.

As I've said before, while BIP 17 is the best solution right now, I have no objections to a similarly clean solution being used. I'm fine with spending more time to address any concerns with it, including a "remake" if that's wanted.

You (and the guy telling Gavin to debate Luke's ideas, not his person) have to keep in mind that Gavin is also a person. He's committed substantial amounts of his free time to this project and it must be immensely frustrating to feel like someone's intentionally wasting the little free time you have.

Of course, Luke has also committed lots of his free time to the project, so from his point of view Gavin (and many others?) might be doing the same thing.

After giving this some thought, I believe I do owe Gavin a public apology for not spending more time proposing BIP 17 earlier, before he spent all that time on BIP 16.

[-ck]

I'd like to point out that as a benevolent dictator coordinating a project like cgminer, it is much easier for me to selectively take parts of Luke's code and selectively ignore things he tries to push that I disagree with. There is a lot of merit to the leader of a project having that kind of power. This is not a vote either way on this issue by the way. Nor am I suggesting that we should necessarily be giving that power to Gavin. However, it works for Linux Kernel with Linus at lead which is a much bigger project and complex codebase than bitcoin is, and it works for the various projects I work on which are much smaller.

[jcp]

I would immediately support any plain multisig scheme or sane long-address multisig TX proposal as possible first-stage on our way to P2SH to allow people play with it and get more time for preparing P2SH deployment.

+1.

I'd be much more in favor of using earlier multisig efforts to classify as IsStandard and creating OP_HASH multisig transactions: https://gist.github.com/39158239e36f6af69d6f or https://gist.github.com/dba89537d352d591eb36

Developing such a large change as P2SH should be reached by consensus after sufficient discussion. Many didn't even hear about P2SH proposals until very recently. Something like P2SH may eventually be necessary for large transactions, I do see a lot of potential value in it (and think the developers put in a lot of good work coding & testing, which is highly commendable), but it is an endeavor that must be developed with sufficient deliberation and consensus. In the meantime, we should begin accepting multisig transactions as soon as possible, with a minimum of code change/risk for miners and users until P2SH has been fully explored. I'd be much more comfortable if there were not been any bugs discovered in P2SH code in the past weeks (let alone months), unfortunately there have been substantial non-trivial bugs in the P2SH code that had to be fixed.

I've switched my hashing power to deepbit.

[CoinHunter]

Its dangerous to let Luke-Jr have anything to do with code for bitcoin. His recent behaviour of sending a DMCA notice to an alt coin dev shows what he really believes. Which is sending men with guns to your house if you do something he doesnt like.

This sort of action makes it too risky to allow him access to insert code in bitcoin that will allow him to take it down or worse threaten companies. Using your mining pool to bully alt chain devs then if hat doesnt work using the gun in the room is enough to disqualify him imo.
'

Well as a competitor to Bitcoin I would actually very much like Luke-JR to get more power within the leadership group or even just stick around doing what he does......

People think when it comes to software development and protocol improvement the best thing is this massive debate over every small change... I disagree. Bitcoin isn't really at the stage where it just needs a few minor tweaks here and there as it sails off to its magical 21 million coin sunset. If Microsoft had this same "development model" we'd be on Windows 3.11 instead of Windows 7 or 8.

We'll see with SolidCoin in the next month or so, a complete rewrite, thin clients the default transaction method for users and out of the box ease for developers to integrate with their sites. All because we agree on what needs to be done and work towards that goal. Few disputes and if they are people are reasonable and decide what's best for the project.

[muyuu]

It really strikes me how much is all this about politics/ego and how little about technical decisions.

I'm quite busy lately and I'm not following the project enough to pass technical judgement. Didn't even register to the forum until recently, thinking I should really study a fair bit before finally doing so, as it's all available here.

This is the single most striking difference between what's advertised and the real bitcoin: it really depends on a few people VERY directly.

Some of the arguments here... seriously?!

I'd really appreciate if you guys left aside personality cults and moral judgement.

[da2ce7]

I have been following this façade the entire time; even-tho I am not a core developer; I think that I can come to some sort of opinion.

In my experience those who are so-called 'poisonous' critically 'complain about things, spread FUD, and DO NOT provide an viable alternative'

Now, in this case Luke has.

• Complained that BIP 16 is 'ugly' (it is, imho).  Saying that there should be a better solution.
• In the technical decisions there are a few cases of 'this will have more issues than this' but overall not really.
• Luke has provided a viable alternative providing solutions to the problems that he claimed BIP 16 has.  (and is creditably calming that he is willing to maintain that solution).

This represents only one part of the things that 'poisonous' people do.

If both implementations BIP 16 and 17 are implemented and of high quality; it is the technical merits that should shine through.  What Luke has done is provide a viable alternative to his preserved problem.  Nobody should complain about that; the community is free to reject his proposals just as they are free to reject Gavin's likewise.

The developer-summit where after a fixed amount of time the core developers (including Luke) vote on what direction they want to take Bitcoin sounds like the reasonable solution to me.  Just we have three options to vote for now:  None. BIP 16. or BIP 17.

Either way.  I think that we should all take a chill pill; keep the debates technical, not emotional, and grow very thick hides.

EDIT: Spelling

[ripper234]

Its dangerous to let Luke-Jr have anything to do with code for bitcoin. His recent behaviour of sending a DMCA notice to an alt coin dev shows what he really believes. Which is sending men with guns to your house if you do something he doesnt like.

This sort of action makes it too risky to allow him access to insert code in bitcoin that will allow him to take it down or worse threaten companies. Using your mining pool to bully alt chain devs then if hat doesnt work using the gun in the room is enough to disqualify him imo.

Two comments:

1. CoinHunter, the SolidCoin lead, has demonstrated his lack of gratitude and respect towards Bitcoin and developers  multiple times. Luke-Jr's DMCA was spot on. Anybody can fork Bitcoin, but they should abide by the terms of the license (which in this case simply meant including a text header).

2. Attacking alt chains isn't evil per say in my book. I support alt chains and think they're important, but likewise it's important that all chains, primary and alt, build up resistance against all kinds of attacks, be they bugs or 51% attacks (e.g. not enable merged mining so fast). Luke-Jr's attack, while not pretty, helped build this kind of immunity - the next alt-chain will learn from the mistakes of the one Luke attacked.

Regardless of these two positive comments about Luke, if I had to choose, I'd choose Gavin (sorry Luke, I haven't seen any direct evidence that "you're poisonous", but I trust Gavin and I assume he's referring to a lot of discussions that took place elsewhere ... I don't read all threads).

[anu]

People think when it comes to software development and protocol improvement the best thing is this massive debate over every small change... I disagree. Bitcoin isn't really at the stage where it just needs a few minor tweaks here and there as it sails off to its magical 21 million coin sunset. If Microsoft had this same "development model" we'd be on Windows 3.11 instead of Windows 7 or 8.

The BIPs have nothing to do with software. They are changes in the standard. Bitcoin, despite it's version number is now production software which can't be treated like an academic toy. TX scripts are cool and all but most of all the system must keep running.

You may have noticed that OS/2 was lightyears ahead of Windows 3.11, technically, and even Windows 95 was just Windows 3.12 in fact. But where is OS/2 today? The secret to the success of MS was not technical superiority, it was network effects. Most ppl did not care about preemtive multitasking. Most ppl don't care for scripted transactions. They want the simple things to work.

[ripper234]

Most ppl did not care about preemtive multitasking. Most ppl don't care for scripted transactions. They want the simple things to work.

Most ppl don't know how to secure their wallets.
Most ppl want to be able to buy a little bit of BTC without installing a dedicated trojan-free linux machine to hold their coins.

This is what P2SH is about.

[CIYAM]

Most ppl don't know how to secure their wallets.
Most ppl want to be able to buy a little bit of BTC without installing a dedicated trojan-free linux machine to hold their coins.

It seems there are numerous projects involving mobile phones, deterministic wallets, two step authentication and the like that this does not seem at all to me to be such an incredibly serious problem that needs to be solved in the protocol right now.

That being said of course I support progress that will improve Bitcoin - I just hope level heads will prevail.

[ripper234]

Most ppl don't know how to secure their wallets.
Most ppl want to be able to buy a little bit of BTC without installing a dedicated trojan-free linux machine to hold their coins.

It seems there are numerous projects involving mobile phones, deterministic wallets, two step authentication and the like that this does not seem at all to me to be such an incredibly serious problem that needs to be solved in the protocol right now.

That being said of course I support progress that will improve Bitcoin - I just hope level heads will prevail.

One of the core Bitcoin values is "you don't need to trust an organization ... just trust the code (which is open for review)".

Doing this at a protocol level is the only way I'm aware of of achieving true security. Otherwise, by definition, there will always be one address that owns the bitcoins in question ... this address has to be stored in the RAM of some device, sometime, in order to be used ... and can then be stolen*

* One exception is perhaps offline transactions ... which is not great on the usability scale.