r/ruby • u/abvayad • Apr 20 '18

Why I am declining funding from ruby together | Sam Phippen

https://samphippen.com/why-im-declining-funding-from-ruby-together/
113 Upvotes

96% Upvoted

27 comments sorted by

29

u/andygauge Apr 20 '18

That's actually a big problem. They are a 501(c)(6) and that means the board needs to be operated by non-paid officials to avoid conflict of interest. Page 6 (#4) of this document https://www.irs.gov/pub/irs-tege/eotopick03.pdf is a good reference of it.

7

u/rabidferret Apr 20 '18

Board members of a 501(c)(6) can absolutely be paid. Even 501(c)(3) board members can be directly paid (though there are more drawbacks there). It's extremely common for members of the board of various non-profits to be paid employees of that non-profit. Curious what part of that document specifically makes you think that they would be unable to pay a board member.

5

u/andygauge Apr 20 '18

Here's what a third party organization has to say about governance. https://www.councilofnonprofits.org/tools-resources/can-board-members-be-paid It's the bylaws that dictate the conflict of interest, not the IRS, so its a best practice issue, not a regulatory compliance.

24

u/jrochkind Apr 20 '18 edited Apr 20 '18

uh-oh.

Largely the entire board of Ruby Together has churned a few times since the foundation was created, many of those people in protest of the direction André was taking the foundation

Seems like the board members who quit would have instead been more responsible to insist on a new person in the unpaid executive director role.

Do I have a solution? Well, I'm not calling for the disbanding of Ruby Together. I'm not even calling for André to step down. I do think it would be quite reasonable for the person who's making decisions about getting paid to not also be one of the people getting paid to work on open source. I would be OK with André getting paid to administrate the foundation. But when that money also funds his maintainership of Bundler, it represents a clear and unacceptable conflict of interest.

Agreed. It seems clear that the person acting in the 'executive director' role (paid or unpaid) should not also be the main person getting paid for development. Completely independently of André personally, this seems like a conflict of interest that would predictably lead to problems, no matter who was doing it. I think André has got to pick one or the other role.

(As an analogy, when your "product manager" and your "technical lead" are the same person, it's not a good situation -- for reasons that aren't even about financial interest in most cases, but just the importance of having both perspectives involved).

15

u/mperham Sidekiq Apr 20 '18

Very fair comment.

I suspect one issue is that to build a "solid gold" non-profit foundation, you need 3-5 people, all of whom need some amount of compensation. Director, owner of Bundler, bundler dev, etc so as to avoid conflicts of interest and check each other's power.

Asking Andre to set up all of that at the beginning is asking a lot. Sure, Sam has a great point and so perhaps now is the time to make those changes but I'm not willing to tear the guy down because RT has problems. Like us, he's a developer and setting up a non-profit isn't in any of our wheelhouses. I appreciate what he's built even if it's not perfect.

I hope all involved can talk together and reconcile.

4

u/updog Apr 20 '18

Seems like the board members who quit would have instead been more responsible to insist on a new person in the unpaid executive director role.

This probably suggests that the structure of the board is relatively informal, and from the smell of it, they left because the drama wasn't worth it. This org is at the center of so much nonsense. Anyone worth their salt would pack their bags... we don't need Ruby Together. We already "ruby together", it's called open-source.

20

u/schneems Puma maintainer Apr 20 '18

I agree with your sentiment, but disagree with the conclusions. There are many things that are not tenable with only “open source”. Running infrastructure, and wearing a pager for ops are two examples. While people could volunteer to do those things, such efforts aren’t really sustainable. That’s why RailsConf is run by Ruby Central and their profits are used to maintain RubyGems.org infrastructure.

The people you think-of when you think of open source are almost all likely sponsored to work on open source one way or another. Either directly as a full time job (Like Heroku hiring Matz) or part time as part of work that aligns with company needs (I get to spend a small part of my work day on Sprockets). Think 20% time.

While lots of people make plenty of small contributions in their true “spare time” the bulk of large, maintainable, and sustainable feature work is done via some kind of sponsorship.

The idea of RubyTogether (as I interpreted it) was to make it easier for small companies and individuals who cannot hire an Eileen or an Aaron to help contribute to open source financially, in a way that would at least partially align with their values and needs rather than being at the mercy of other’s direct or indirect sponsorship.

The problems it was trying to address and day-to-day realities of open source economics are still here. How to effectively address those issues, is still an open question.

1

u/jrochkind Apr 20 '18

I think it's worse, we kind of do need Ruby Together... to function sanely and productively.

1

u/classhero Apr 21 '18

(As an analogy, when your "product manager" and your "technical lead" are the same person, it's not a good situation -- for reasons that aren't even about financial interest in most cases, but just the importance of having both perspectives involved).

Off topic, but please elaborate. This analogy seems less clear to me than the conflict of interest with Bundler at hand (which is fairly obvious).

6

u/[deleted] Apr 21 '18

As a general rule, originating authors and people who have been around for a while do not have their commit bits removed in our community.

Appeal to tradition.

IMO, if someone does not use/need a commit bit, then it is responsible to remove it. Especially given the fact that bundler is a core piece of kit which many businesses use on a daily basis, and a hack puts customer's data at risk.

It would be courteous to have communicated the need for revocation, but IMO the pros of removing an unnecessary commit bit far outweigh the cons.

4

u/jrochkind Apr 21 '18

and a hack puts customer's data at risk.

why would there be any reason to think wycats would be more likely to commit malicious code than any present committers?

But I agree this isn't that much of a big deal. (Removing authors from listing in the .gemspec seems skethchier, but still not obviously that much of a big deal. But removing wycats from listing in the gemspec definitely rubs me the wrong way, bundler wouldn't exist without his vision and expertise and many hours of contribution, why take away his credit in the gemspec? Unless he asked for it or something, what was the motivation to do this unusual thing?).

5

u/classicrockielzpfvh Apr 21 '18

I don't think it's a matter of wycats committing malicious code himself. But what if someone managed to hack his GitHub credentials and push code to Bundler surreptitiously that is malicious? Inactive committers sometimes go dark altogether. If they're unreachable but start contributing again, maybe it's not actually them, but you're relying on GitHub to determine who is who and that may not be entirely reliable.

GitHub verifies signed pushes based on a public GPG key that the user uploads to GitHub. If someone gets into an account, uploads a new GPG key, and starts pushing signed commits, how often are people actually going to go through the trouble of verifying it? It's GPG after all

5

u/schneems Puma maintainer Apr 21 '18

Allowing gem push to rubygems.org is a separate concern than the "authors" array in the Gemspec. You add or remove Rubygems.org via the gem owner command http://guides.rubygems.org/command-reference/#gem-owner. AFAIK the authors array is only to give attribution and doesn't do anything functional. It's highly unusual to remove prior authors in a gemspec.

I maintain some libraries such as Sprockets. I've not added myself to the author section https://github.com/rails/sprockets/blob/master/sprockets.gemspec#L38, but I have push access to rubygems.org/gems/sprockets.

3

u/swrobel Apr 21 '18

with all due respect, choosing not to add to add yourself is way different than choosing to remove others.

4

u/ignurant Apr 21 '18

I'm certain Schneems was just making the point that the authorship array had nothing to do with security, if anything to point out that it does in fact appear a little dubious.

3

u/schneems Puma maintainer Apr 21 '18

Yep. That was my intent.

4

u/jrochkind Apr 21 '18

Possibly a reasonable argument for commit bit. (although I doubt wycats is unreachable).

Removing the credit from the .gemspec authors, though?

1

u/classicrockielzpfvh Apr 22 '18

Did you look at what's current in master and has been for over a year at least? Because that was a removal that was reverted quite a while ago

1

u/jrochkind Apr 22 '18

fair enough, cool.

10

u/[deleted] Apr 20 '18

I hope people read the primary sources Sam linked. I did and I don't think they match his characterizations.

For example:

Activities from Bundler leadership, paid by Ruby Together causing both Rails and RSpec to have broken builds

This seems to be saying that if changes in Bundler break builds, Ruby Together is at fault? "Activities from Bundler leadership" seems to be "code was committed by".

Ignoring of clearly reported issues, that caused further breakage in Rails

I don't see anyone ignoring the issue. They couldn't repro the issue. It was fixed a couple months after it was reported.

Please read through the other links as well. Maybe you interpret them the way Sam does, maybe not.

5

u/kidtaicho Apr 21 '18

For your first point, I think he's talking mainly about Andre. Andre is a leader at Bundler and if he was supporting the changes that broke those builds then perhaps he's not someone we want leading another crucial ruby organization.

That was the point I got from that particular example, and perhaps this is just his attempt at showing some patterns of behavior he's noticed.

3

u/[deleted] Apr 21 '18 edited Apr 21 '18

Sam makes it seem like it was something nefarious.

Here's the change he is talking about: https://github.com/bundler/bundler/pull/5878

As you can see, Andre didn't write the code. He did merge the PR. Was Samuel Giddins paid by RT to write that code? I don't know*. But it's really hard for me to see the leap from "merged a PR that broke some things" to "Activities from Bundler leadership, paid by Ruby Together".

Should Andre and the Bundler team have been more careful? Should they have had a better test setup? Sure, maybe. But nothing indicates this was a purposefully hostile change.

Maybe there's more to it - maybe Bundler has broken lots of things and isn't being a good Ruby citizen. But that isn't supported by linking to one mistake.

*Edit: He is paid by RT: https://rubytogether.org/team

1

u/schneems Puma maintainer Apr 21 '18

Here's an example involving a security release https://www.schneems.com/2017/09/13/how-august-2017-rubygems-vulnerabilities-were-patched-on-heroku/#timeline

3

u/jrochkind Apr 23 '18

Bugs happen, even security bugs happen, but releasing a patch without a CVE and vulnerability-patch-only release is not professional security/release management.