02:05 - André Arko Introduction + Bundler

04:28 - Ruby Together

10:52 - Ruby Central

14:23 - Ruby Together Timeline

16:01 - Open Source People Depend on vs Open Source as a Hobby

17:03 - Corporate Member Rights / The Structure of Ruby Together

20:19 - How the Board Makes Decisions

23:00 - Membership Numbers

24:03 - How Voting Works

26:58 - How much work is involved in maintaining these projects?

30:08 - How is work doled out?

33:41 - Future Plans and Community Impact

40:28 - Getting People Involved

43:34 - Lessons Learned

45:23 - Code of Conducts / Community Values

Picks

Boundaries: A talk by Gary Bernhardt from SCNA 2012 (André)
The Protomen (André)
Bubblesort Zines (André)
Don't Make Me Think: A Common Sense Approach to Web Usability by Steve Krug (Saron)
F.lux (Saron)
Hue (Saron)
Madison Ruby Day 1 (Coraline)
Madison Ruby Day 2 (Coraline)
Survive Escape From Atlantis 30th Anniversary Edition (Coraline)
Angular Remote Conf (Chuck)
React Rally (Chuck)
Alcatraz Books by Brandon Sanderson (Chuck)

Special Guest: André Arko.

 

Alright. Looks like it's just us.

Woohoo!

ANDRÉ: Alright.

Okay.

ANDRÉ: [Chuckles]

Except there's no 'just' about us, right?

Yeah.

ANDRÉ: Yeah, okay.

I like that.

Hey everybody and welcome to episode 224 of the Ruby Rogues Podcast. This week on our panel we have Coraline Ada Ehmke.

Good morning.

Saron Yitbarek.

Hey, everybody.

I'm Charles Max Wood from DevChat.TV. And this week, we have a special guest. That's André Arko.

ANDRÉ: Hey there.

So André, first off I just want to thank you on behalf of the community for all the work you do on Bundler.

ANDRÉ: Yeah, absolutely. Thanks a lot. It's been a really rewarding process to work on it and get to talk to everyone who works on Ruby and uses Bundler as a result.

I just remember the bad old days where a good day with dependencies was when you put your gems in one by one and you only got one or two dependency conflicts. So...

ANDRÉ: Yes.

Since Bundler handles all that, that's really nice. [Chuckles] ANDRÉ: It is.

I used to have to do binary searches to figure out which gem was causing conflicts. It was a pain.

Yeah. I would pull all the gem references out of my configuration in my Rails app or whatever and then put them in one by one and work out the conflicts that way. So, I'd be changing version numbers and crap. Ugh.

ANDRÉ: So bad. I was also around for the bad old days. And my favorite story from back then is the time that I started a new job in probably 2007 or 2008. And they handed me my brand new work laptop and said, “We're really hoping that you'll be able to get the app up and running on this laptop inside of a week.” [Laughter]

Oh, man.

ANDRÉ: And I accomplished it after only two and a half working days and they were very impressed.

Wow.

That's your interview, right? [Chuckles] ANDRÉ: Yeah.

Here's a laptop. Set up the app. Good luck. [Laughs]

At least you didn't have to do that on a whiteboard.

ANDRÉ: Yeah.

Oh, yeah.

ANDRÉ: But yeah, it actually took two and a half days of installing gems and trying to track down what other things that weren't in the readme needed to be installed and what versions. And does it work yet? And it was amazing.

Bundler now is a real asset to the Ruby community. And I know that a lot of other languages are struggling with package management. And Bundler solves so many of those problems for us that it becomes invisible to us. But it's a real problem in other communities.

Yeah. I won't talk about how they've revamped npm, like completely rewrote parts of it to do what Bundler does for the Node community.

ANDRÉ: Yeah. I do a lot of work with Ember lately and definitely the biggest thing working on an Ember app, I miss features from Bundler that don't exist in npm on an almost daily basis. So yeah, totally. I totally understand that.

Yup. Well, we actually wanted to talk about Ruby Together on this show today.

ANDRÉ: Yeah, absolutely.

It's exciting because we have both you and Coraline here. You're one of the developers whose projects are being supported by it and Coraline's on the board from what I understand.

That's correct.

ANDRÉ: I am actually also on the board, full disclosure. The backstory is actually kind of interesting. So a couple of years ago now, I spoke at RubyConf Australia. And at some point while I was in Australia I wound up randomly sitting next to the then CTO of Stripe at dinner. And we were just chatting. And he was telling me about ways that Stripe was using Bundler and that they were having questions and sometimes running into problems. And I was saying that I was really interested in working more on Bundler but that my time on Bundler was basically constrained by the fact that I had to have a job to make money.

And working on Bundler was really enjoyable but I had to limit my time as a result of having to make money. And he just gave me this look and then said, “Well, if Stripe just gave you money, would it mean that you could fix these problems with Bundler that we care about faster?” And I said, “Well, yeah?” [Chuckles] And so at some point, it was probably six months later, but Stripe actually said, “Okay, well we'll just give you this money every month. And maybe sometimes you can come in and tell us if we're using Bundler wrong.”

And so, that actually made me start to think, “Oh, well this is actually a problem that's spread across a lot of companies.” And no other [company] has ever thought of just handing me money as the solution [chuckles] to it. But it absolutely worked as a way to increase my time that I had to fix things that I knew needed to be fixed or to fix problems that companies were reporting. They could use features to help them develop faster or whatever. And so, that actually kicked off this idea for me of, well, companies actually depend on Bundler on an every single day kind of basis. What if they were able to guarantee that things were actually getting developed and being improved and non-breaking as new versions of everything comes out by splitting the cost of that development across all of them?

And so, I actually spent a while just super focused on Bundler and trying to see if I could convince companies to chip in money to help me spend time working on Bundler. And it was tough going for a while. I spent probably a year talking to different people about this and getting a response that was like, “Well, that seems kind of good. We'd definitely like more work to get done on Bundler.” I got a lot of companies saying, “Well, we don't feel like Bundler causes us a lot of pain so we're not very motivated to give you money to make it better as opposed to other tools that do cause us a lot of pain. So, we would be motivated to pay money to improve those.” And so, after talking with a bunch of different companies I made it to the point where as well as Stripe, Engine Yard had also decided that they wanted to join this thing.

And that's when I realized that it was actually probably a terrible idea to have these companies giving money to me directly. Because that's weird and I don't want to be that kind of open source developer. And so, I realized that I needed to set up some kind of company to handle, act as the intermediary for companies that want to support open source development for open source that they use. And so, as I started to look into incorporating, I actually wound up talking with this really great lawyer who said, “I totally see what you're talking about, this thing where companies pitch in together to fund your company so that you can afford to hire developers to work on open source software. That actually sounds exactly like a particular type of non-profit.”

For the IRS and the US it's a 501(c)(6) non-profit which is, charities are a 501(c)(3). So, they're non-profit under the same non-profit law. But they're trade associations rather than charities, which is like the IRS's way of saying, “Oh, if you're a company that takes money from other companies...”

To contribute to the field.

ANDRÉ: Right, exactly. So, if multiple companies that engage in the same trade are cooperating to promote that trade, then that is absolutely a trade association. And that comes with some really surprising to me but really great benefits of those companies don't have to pay taxes when they contribute to the trade association. And the trade association doesn't have to pay taxes on those contributions. Instead it's able to just take that money and spend it on things that benefit everyone involved in that trade. So, the...

How difficult was that to set up?

ANDRÉ: Again, because of having a really, really great lawyer, it wasn't that hard. It did end up costing, I want to say maybe four or five thousand dollars total, which is a lot more expensive than just setting up an LLC which you can usually get done for less than $500. But we were able to not only incorporate as a non-profit in the state of California, but we were able to also apply to the IRS for trade association non-profit status and get our application approved in less than eight weeks.

Wow.

ANDRÉ: Which is really, yes, [chuckles] for anything involving IRS paperwork was super amazing. And so, we...

Is this attorney someone you can shout out if somebody else wants that work done?

ANDRÉ: His name is, and I'm possibly butchering this, Brian Mikulencak. And he has a law firm in Austin. But he was just fantastic to work with and very knowledgeable about this particular subbranch of corporate and tax law. He's I guess worked with some other trade associations in the past and was able to be super helpful to me as a result. It was super great. Well, we'll totally link to him in the show notes.

Is Ruby Central set up as a trade association or are they...?

ANDRÉ: Actually Ruby Central is set up as a 501(c)(3) charity. So, Ruby Central is actually really quite old. They were founded initially in I want to say 2001. And something interesting happened with the IRS and software projects a few years ago, around 2012, 2013. So, for a long time open source projects, any time that they needed a company to be involved in the governance of the open source project would start a 501(c)(3) charity because 501(c)(3)'s are granted basically full immunity to taxes by the IRS. Any money that you give to a (c)(3) you can deduct from your taxes and they don't have to pay taxes on. There are minor exceptions but that's the blanket rule.

And the theoretical intention behind charities is that they are doing work that goes to benefit humanity, I guess is the way that it's worded. And so, at some point the IRS said, “Hey, wait a minute. Just because you happen to be involved in a project that gives away source code for free doesn't mean that you're actually doing work for the good of humanity and that we should let you not pay taxes ever.” There are definitely commercial enterprises that give away source code. But that's just a strategy of theirs. Actually, Red Hat comes to mind. They give away a Linux distribution but they're absolutely a for-profit concern even though they give away a Linux distribution.

And so, around 2012 or 2013 the IRS basically had this institutional crackdown on applications for charity status for software projects. And it's more or less impossible to get designated a 501(c)(3) charity now. They basically allowed all of the applications that they approved in the past to be grandfathered in. But there's somewhere between very small and no chance that a software project today can get that full on charity status.

And so, a trade association is actually a really great compromise because it means that it is taxfree for the trade association and for the companies involved in the trade, which is the only scope that Ruby Together is actually interested in. And it means that the IRS isn't as I guess carefully 'oversightful' of exactly what you're doing with your money because the assumption is that if the companies in the trade are dissatisfied with how you're utilizing their contributions, that those companies will just stop contributing. As opposed to charities where there's this implicit policing by the IRS that if you're not using money given to the charity for the benefit of everyone in general, that the IRS should investigate and take away your tax-free status.

So, it turned out to be actually really great that we can get full charity status. Btu it was this very interesting kind of situation where it turns out that the IRS doesn't really like open source as a charity kind of organization anymore.

Gotcha.

Hmm. Interesting.

ANDRÉ: That's possibly relevant to nobody. But if you're thinking of starting a company around an open source project, that definitely, that's the one time it's super relevant.

And how long has Ruby Together been in existence?

ANDRÉ: I started trying to put the company together in March of 2015 when I realized that both Stripe and Engine Yard were willing to pitch in to fund work on Ruby infrastructure. And I think we got our full IRS status by early May. So Ruby Together, we actually launched the company and started operating a few weeks before the IRS granted us status officially. But that's how you normally work because the IRS is backwards. And when they grant you non-profit status, it's retroactive backwards in time. And it's really funny how that whole process works. We launched in April. And it's August now so it's been four or five months.

And it's actually been really great to see the kind of reception that's happened as people have seen that it exists and then learned more about it. We've had other companies sign up just in the last month. Yammer joined as a corporate member. And actually this is kind of cool. I wound up talking with DHH about it. And the thing that absolutely surprised me, he's actually really positive on the idea of Ruby Together and companies contributing money to guarantee that developers are able to maintain stuff that companies depend on. And so, even though he I guess is very against the idea of paying money for open source development work in general, DHH actually signed up Basecamp as a corporate member of Ruby Together just this last month.

That's awesome.

Yup.

ANDRÉ: But yeah, that's totally great.

So, what do you tell the naysayers? I'm sure there are people out there who are looking at this and going, “Well, it's open source. It's always been free.” ANDRÉ: Yeah.

And you know, “People just work on it in their spare time and that's what's great about it.”

ANDRÉ: Totally. And the model of people who want to work on software as a hobby, I'm not trying to interrupt or disrupt that in any way. I in fact work on software as a hobby myself. And that's totally cool. The specific thing that Ruby Together is trying to target is the idea that when there's open source software that people depend on and use to accomplish I guess their business, honestly. That's how the RubyGems infrastructure works today, right? If you're a Ruby company or a Rails shop your business is one of the foundations of your software business is Bundler and RubyGems and all of the things that make it possible for you to build your software.

So, when I'm looking at the idea of members and sponsors or I guess corporate members, what rights do they have? I see that they can vote on board members, but do they have the right to vote for specific features or specific things that they want to see? Where does that line come in?

ANDRÉ: So, the structure... I spent a really long time thinking about how to structure Ruby Together and discussing it with other people who are involved. I guess this is a good time to give a shout-out to the board members who have agreed to help make corporate decisions or I guess decide what directions we should go in and what things we should focus on. So, the founding board members include Aaron Patterson, Steve Klabnik, Terence Lee the head of the Ruby Stack at Heroku, Ines Sombra from Fastly, and Sarah Mei who is also on the board of Ruby Central and has been really great helping us coordinate there, and Joel Watson. And then Coraline has graciously agreed to join the board to fill in after Aaron Patterson realized that his schedule was a little overbooked which I can't blame him for.

And so, I selected that group specifically to attempt to have representation for a broad spectrum of different people who use Ruby for different reasons. And so, the structure of Ruby Together is actually designed both to help individual Ruby developers and help companies that use Ruby at the same time. And so, the way that it's set up is unless you ask us otherwise, we only want to take money from members once a month. No pre-payments. No upfront. We're trying to avoid fundraising syndrome where we say, “We have all this stuff that we want to do. Now give us money for the next year.”

You don't want to be NPR.

ANDRÉ: Right.

ANDRÉ: I not only don't want to be NPR but I don't want to be one of those fund raisers that's like... you know, and this has happened with the Ruby community in the past where there have been fund raisers for projects that sound great and it's been ambiguous in real life in the end, what gets delivered and whether it actually does meet what the goals were or not. And it's so hard to have accountability when all the money is thrown at you upfront and then you just go off into your cave and people hope that you come back with the thing that they want. And so...

I can see the other issue too that if you collect say annual payments and you spend your annual payments this month...

ANDRÉ: [Chuckles]

Then you have to go get more annual payments next month.

ANDRÉ: Yes, exactly. And I don't want that to happen either. And so, structuring it so that its monthly contributions provides this really great virtuous cycle of feedback where I can take people's monthly payments and then come back to them in a month and say, “Hey, this money was amazingly helpful. Look at this stuff that we got done that is making a real difference in your and everyone else's daily life.”

Yeah. So, you're talking about some of the decisions you're making as far as how the money gets spent to help. Looks like you and Daniel do the work on Bundler, RubyGems, and RubyGems.org. How are those decisions made, then? Does the board make those decisions? Do they hold a meeting and vote? And then, “We're going to pay André this much. We're going to pay David this much. We're going to contribute this much to these goals.” How does that all work out?

ANDRÉ: Absolutely. So, the way that that works is the exact budget amount that we have fluctuates as we sign up new members. That's not a solid amount.

Mmhmm.

ANDRÉ: But the board sets which projects we're going to attempt to fund as we have funds available and sets things like the rates that we pay developers when we hire them and which projects to hire developers to work on and in which order. So, the way that members are able to participate in the decision-making process is every member as part of their membership is invited to the Ruby Together members’ private Slack group chat. And so, we spend time in there talking to members about what their concerns are and what projects they care about to get an idea of what individual members' priorities are. And then the board reaches consensus during board meetings about which projects they think that the community cares about.

And so, that's part of why I deliberately tried to find a board that represented a good cross-section of the Ruby community so that as they reach consensus about what projects to support in what order, it's a way to say, “This makes sense for the interest of Heroku and all of the people running Ruby apps on Heroku. This makes sense for the interest of individual Ruby developers. This makes sense for companies that use Ruby. This makes sense for the non-profit organizations involved in Ruby.” And so, the board ultimately makes the decisions about what projects to fund and in what order. And the members are able to present the concerns that they have to the board and the members are also able to elect the people who are on the board.

So, this initial set of board members was selected by me because I needed a board to form the company with. But as time goes on, the entire board will ultimately be elected by members. And then those board members as elected representatives of the members will decide how to spend the money that we receive.

So, I imagine the majority of the members are corporate members. Is that correct?

ANDRÉ: We launched with two initial corporate members of Stripe and Engine Yard. And we offered the option both for companies to join and for individual Ruby developers to join. There's actually been a really strong positive response amongst individual Ruby developers. And so today, we have about 100 individual Ruby developers who are either members or what we call friends of Ruby Together which means that they're pitching in but the amount that they're giving isn't over the membership threshold. Today that's $40 a month to become a member with voting rights. And so, any contribution under that level makes you a friend of Ruby Together. And so, members and friends combined is around 100 individual developers. And then companies-wise we're today at 12 different companies that have joined Ruby Together and are contributing every month.

Yeah.

I'm curious about how the voting works. Do individual members have the same voting weight as corporate sponsors?

ANDRÉ: So, they do. Each corporate member and each individual member gets one vote in the board elections. So today, that looks like there are about 12 corporate votes and there are about 80 individual votes, if we held the elections tomorrow. And so, that structure is also deliberate. And it's possible to change if it seems like that's not working for some reason. But it was actually a concern as we were working on the by-laws, how the company and how the board would work, that we didn't want to basically allow the board to be elected by whoever had the most dollars at stake. Because from the other direction, that is actually a problem that has happened where an individual company effectively becomes rather than being a member or contributor they become the sponsor or the patron of an entire project, or sometimes an entire team, right?

Mmhmm.

Yeah, that's exactly what I was thinking as well.

ANDRÉ: So, once upon a time the entire JRuby team, the entire Rubinius team, and the most active members of Rails core all worked at the same company at the same time. That's exactly the kind of situation that I'm trying to avoid with Ruby Together by ensuring that no individual company is able to get enough influence to hi-jack the process.

And this isn't set in stone but today we actually have a hard limit on the maximum amount of money that we're willing to accept from any one company because we don't want to become dependent on a single company to be able to operate at all. And I feel like it's a truism especially since Ruby gets used a lot at venture capital-backed startups. Companies come and go. But the tools that we use and the community that we have is the thing that stays. And so, that's why I'm trying to make sure that Ruby Together is something that's aligned with that community and that's supporting those tools whether or not any single individual company is still around next week, right?

So, we actually deliberately structured it so that a lot of companies are cooperating to produce this function rather than really aggressively pursuing just one or two companies for a larger amount. Because I don't want to feel like there's any single company that can demand that we do what they want just because they're the single source of funding. And I don't want to stay up late at night worrying that that one company is just going to decide tomorrow that they don't actually have money to participate anymore and then have to shut everything down.

So, it seems like you're working around making these decisions as far as which projects to tackle and things like that. And the board is involved in choosing the projects to jump on. But I know somebody is out there thinking, “Okay. Well, Bundler and RubyGems and RubyGems.org all work for me right now. So, is there really that much work that needs to be done...” ANDRÉ: Yeah, absolutely.

“To collect this level of donation?”

ANDRÉ: Yeah. And so, I guess there are two sides to that coin. On the one hand, and I think most people just haven't realized this, a lot of work, a surprisingly large amount of work is required just to keep everything working all the time.

And so, that is actually why we initially targeted Bundler as a project and myself as maintainer there. And RubyGems.org as a project and David as the maintainer there. Because as I was getting Ruby Together, we compared notes and we realized that by our best estimates we needed about five hours a week just to make sure that everything kept working. No actual improvements, no dramatic changes, just like, “Hey, is this going to work next week? Hey, is this going to work with the next version of Ruby? Hey, is this going to work with the changes that AWS is making to their infrastructure in the next announced round of changes?” And so, there's just this endless low-level stream of things that are continuously going wrong in a low-level way and that have to be fixed in an ongoing maintenance way.

So, my favorite example for this just because it's so dramatic is you all were talking about the bad old days for Bundler so I'm sure you all were around when this happened and you remember it. But hey, remember the time when RubyGems.org got hacked and was down for a week because we had to throw the server away and then we had to download and check the checksum of every single Ruby gem in existence before we could bring the server back up?

Yes.

Yes.

ANDRÉ: Okay. So, that happened because there was a security vulnerability that was known that had a fix that was also known. And RubyGems.org was maintained entirely by volunteers who were like, “Hey, we really need to fix that. I guess I'll put that on my list for this weekend after I'm done with work.” And without someone whose actual job it was to immediately fix the RubyGems.org servers to close that known security hole, that left the opening that eventually resulted in that hack that took it down for a week. And that is a perfect example of why it's actually critically important to, even if it's only five hours a week, make sure that RubyGems.org is still getting security updates, make sure that RubyGems.org is still patching the Nginx server when there's an update for that, patching the OS when there's an update for that, et cetera, et cetera, right? It turns out that the bad guys don't actually care that you work on it for fun in your spare time.

And they just want to hack in as quickly as possible.

One thing I was wondering about, the amount, membership amount. Because it's 40 bucks a month, 10 bucks a month, I'm not sure how much the corporate memberships are. But is the idea that a team of developers will work on these fixes and these features full-time or is it that they can take one day out of the week to fully dedicate to this as part of their job?

ANDRÉ: Yeah.

How do you imagine that working?

ANDRÉ: So, actually both. [Chuckles] The way that we're hoping to pull this together is obviously in this kind of initial phase as we're still trying to get the word out that we exist, actually the most common response that I've gotten when I go to conferences and tell people about Ruby Together is they're like, “Wow, that sounds like a really great idea. I just hadn't heard anything about it.” And so, while we're still trying to let people know and convince people that this is a good idea, we definitely don't have enough funding yet to be paying someone to work full-time. And we have this list of projects that we want to support and maintain.

And so, today we have the funding to do this maybe one day a week maintenance work on Bundler and on RubyGems.org, the servers and the infrastructure and stuff like that. As we get more funding, the next thing that I want to support with at least one day a week of work is RubyGems itself, like the gem command and all of the code that loads gems and talks to RubyGems.org.

For a really long time, that project has been maintained by Eric Hodel. He's drbrain on Twitter and GitHub. And he worked at AT&T Interactive where they actually paid him to be the maintainer of RubyGems and RDoc and DRuby and some other things that are all just part of Ruby. And unfortunately AT&T Interactive, this is old news like a year ago or a year and a half ago, AT&T Interactive had some kind of change-up in how they paid that team. And Aaron Patterson who had been working on Ruby Core and on Rails Core at AT&T Interactive and Eric Hodel who had been working on RubyGems on all these other projects were both let go. And as a result that's meant that RubyGems itself actually hasn't had someone working on it except Eric still in his spare time and a couple of other people who in their spare time work on it. But that's meant that it hasn't had solid maintenance of the kind that I'm talking about where you just need that ongoing maintenance to make sure that everything keeps working.

And so, a really good example of this is that RubyGems today has a bug where installing gems that need native extensions on Windows doesn't work for I think not every version of Ruby but for some majority of the versions of Ruby that people are using nowadays. And so, there's this really long thread on GitHub of people on Windows saying, “I thought that everything was broken and then I downgraded RubyGems and suddenly everything works. Thank you, hallelujah.” And so, this bug that no one has had time to fix yet is actually acting as a blocker for people who are interested in Ruby but only have a Windows machine and want to learn it, right? They install Ruby on a Windows machine and it turns out that you can't actually install the gems that people expect you to use in the tutorials until you hunt down this obscure bug that happens to mean that you have to downgrade RubyGems.

So, that definitely affects a swath of developers like you said who'd otherwise be using Ruby. So, that's an example of how Ruby Together can impact the greater community. Are there other examples of how you can impact the community aside from keeping the lights on for individual projects?

ANDRÉ: Yeah, absolutely. So, I guess as part of the greater question that Saron raised about what is it that we hope to do, we actually hope to, once we're sure that the lights are going to stay on long term, there's a bunch of stuff that really, definitely could be improved. And we have strong ideas about how to improve it. But we can't really tackle it until we have a surplus beyond just, “Hey, now we're sure that everything's going to keep working.”

And so, as we're able to pull together more funding and as we're able to make sure that Bundler and RubyGems and those things are stable and will continue to work into the future, the next thing that I'd like to tackle is actually community projects and improvements that help everyone. And so, if we can pull together enough funding, I would absolutely love to hire at least one full-time developer to work on these tools and projects. And honestly, if we raise enough funding I would be ecstatic to hire two full-time devs or three full-time devs, assuming that we can make it to that level of funding. So, already in our backlog of as money comes together and we have time to pay for development work on these projects.

One of the projects that we've been working on and making very gradual progress on, basically we've been migrating all of RubyGems.org over to the Fastly CDN. And so, David as the maintainer of RubyGems.org has sometimes been donating his free time to that, above and beyond what we're able to pay him for on maintenance. And what that will mean once we're done is that people all over the world will be able to install gems from a data center that's local to a region. Today, installing gems means that no matter where you are you have to make a request over the internet to the RubyGems.org AWS servers that are in US West or US East. And so, if you're in Australia or if you're in Europe or if you're in Africa somewhere, all of those places are so far away that even just the round-trip times actually become a significant problem.

I've talked to developers in, where was that? Oh, I was at Rubyfuza in South Africa and talking to developers there about installing gems. And they said that running 'bundle install' for them is a process where you run 'bundle install' and you get up, brew yourself a cup of coffee, drink most of it before 'bundle install' finishes. And that blew my mind because it hadn't even occurred to me that it could take that long at the time. And if you're one of the Ruby developers who's inside the US and is just making requests to the edge of the continent that you're already on, it's a very different situation when every request has to go basically a continent and then across an ocean before it can be answered. So, that's actually just one of multiple projects that we really want to work on.

There's another project. What I would really like to do is put together a community Ruby ecosystem analytics system and dashboard so that anyone who uses Ruby can see what versions of Ruby everyone uses and see what versions of Rails everyone uses and see. It's actually very relevant to us as Ruby developers what versions of all of these tools are actually being used in a day-to-day way. And being able to see how quickly developers and shops upgrade across Ruby versions actually matters from a, “Well, what version of Ruby should I be most familiar with to get a job?” perspective. It matters, “Well, what versions of Ruby should this open source project that I'm working on be compatible with?” And there's just so much potential information there that we could have but we don't have time to unlock yet.

Another project that I feel like every single person that I talk to is like, “Oh yeah, that would be great,” is we want to build a project that you can check out and then run locally like in your office if you're a company or in your data center if you're deploying to servers, that can act as a local Ruby gem server. And so, if you ask for gems that it doesn't have a copy of, it'll go and get them from RubyGems.org. If you have internal gems that you want to publish you can push them to just your local server.

And if you have a data center full of 50 machines that all need to install a new gem, being able to only fetch that gem from RubyGems.org once and then copy it onto all of your local machines, or if you have an entire office and that new developer needs to install gems that you use and they only have to talk to a machine that's local inside your office rather than going off to RubyGems.org to download all 200 gems, that's a huge both productivity win and a huge benefit for companies that just want to be able to package up internal shared code into gems and then share them across the company.

A lot of companies that I talk to are either using dozens and dozens of gems directly out of Git repos which is very, very slow because Git repos are much higher overhead than just a single released gem. And a lot of companies that I've talked to have said that they recognize that this is such a problem that they've built their own duct tape and chewing gum internal gem server to try and solve this problem. I've talked to at least six companies that have all assigned internal full-time developers to work on this for months and ended up with a solution that only mostly works and is only applicable inside their exact company.

And so, this is a perfect example of everyone in the community would benefit if everyone chipped in this tiny fraction of the cost of paying a full-time developer and wound up with software that everyone could use.

André, you talked about project maintainers having to work on infrastructure projects in their free time. In my experience marginalized people don't always have the privilege of working on OSS in their free time. Open source participation by women for example is very low. So, as you hire developers is there the possibility of funding people, at least part-time, who wouldn't otherwise be able to contribute?

ANDRÉ: Yes, absolutely. That's definitely something that I've thought about. And one of the things that I would love to do with Ruby Together is as we have funding to be able to actually pay people to do this work and to work on both all of this maintenance work and all of this community project development stuff that I would absolutely love to get done, I would really like to find people who are great developers but don't have enough time to work on open source as a hobby and be able to both get them paid for their work and get them involved in open source and working with the Ruby community in general. We're approaching the point where... so, I'm starting to think about that now but I think we don't actually have the money to start paying someone just yet. But in the near future as more companies pull together, that's definitely something that's on my mind and that I have in my five-year plan of Ruby Together, right?

Like honestly, what I would love to have happen in a future situation where this is just a generally accepted thing that Ruby companies do, is everyone chips in and everyone produces this stable set of community software that everyone can depend on and that's maintained and developed actively. What I would really like to do is have a way to get both people who don't have time to do this as their hobby involved and a way to get people at different levels of experience involved.

It's actually a very common problem for open source projects to have only people at one level of experience. So, you end up with an open source project where everyone is equally inexperienced and they're resolving problems that already have well-known solutions. Or you end up with an open source project where everyone working on it is at this very high level of experience and they all have a lot of other responsibilities. And so, as a hobby it means that it's just this not super wellcoordinated group of people doing things that they assume are the right thing to do. And I've worked on projects across that entire spectrum.

And so, what I would really love to do is have Ruby Together actively paying people to work on this infrastructure so that there is no single point of failure. There is no single level of experience and there is no single level of, “I have so much free time that this is my hobby, is to write software and give it away.” I would love to get across the entire spectrum for all those things.

One thing that I am curious about is as you've gone through this process, if somebody decided that there was another project maybe for a different language or in Ruby that fits this infrastructure need, I can't think of anything off the top of my head at the moment, or maybe Basecamp quit sponsoring some of the Rails core development stuff and so there was a need there, what things have you run into that you would do differently, setting up an organization like this for open source?

ANDRÉ: [Sighs] I think the biggest thing that I would do differently with hindsight is that I would have talked to companies about what their motivations were and what their concerns were sooner. I wound up just talking to individual people. And so, we wound up launching with a website and a lot of thoughtfully written text around what our motivations were and why we wanted to do this and how it would help the Ruby community. And it was very motivational to individual developers and a lot of them signed up. But when we went to talk to companies it turned out that we basically weren't addressing any of their concerns yet.

And so, it actually took a couple of months to go to companies and listen to them and learn what they wanted to see and what they wanted assurances about and put together all of the information that addressed that. And once we had done that, it was actually much more straightforward to talk to companies because we could say, “Here's all of the questions you probably have. We've already [whipped up] answers to them. Let's maybe talk if this makes sense for you,” versus companies saying, “That's a pretty nice idea but what about,” and then having this long list of questions that we hadn't actually figured out the answers to yet.

There's one more thing I wanted to mention. In July Ruby Together added a provision that they would only support products with a code of conduct. And I just wanted to thank you for putting that through so quickly and making that part of the community values that Ruby Together holds dear.

ANDRÉ: Yeah.

I think that's a valuable step forward for the community.

ANDRÉ: Absolutely. And I definitely feel like it's important to establish community norms that are actively inclusive and make sure that everyone, actually everyone rather than just the people who already feel like they're well-included in the community, are able to join and participate and feel like the community is somewhere where they can build software and do cool stuff with Ruby.

Cool.

Before we get to picks, let's have a quick shout-out to our silver sponsor.

ANDRÉ: So, my first pick is very software-y. It's Gary Bernhardt's talk called 'Boundaries'. And it's one of my favorite talks about building software of all time. And it has really snazzy graphics to go along with it. So, it's pretty great.

My second pick is the band 'The Protomen' which is Mega Man rock opera. If you're into rock opera or Mega Man I highly recommend it. I'm going to see them play in San Francisco tonight. They're pretty great as a live band as well but I also love their albums.

And my third pick is my partner Amy has started doing a monthly subscription service of computer science and math. I guess technically they're zines. They're illustrated guides to different computer science and math concepts called 'Bubblesort Zines'. And they're super great. And so far there's one about how calculators work that starts with how the Ancient Egyptians and Ethiopians counted and did arithmetic and goes up through logic gates and puts together adders into a calculator. And there's one about different sorting algorithms. And they're both pretty awesome. And they're very adorably illustrated. So, that's my third pick.

Alright. Saron, what are your picks?

Sure, I have a couple. So, the first is a book called 'Don't Make Me Think: A Common Sense Approach to Web Usability'. And it's a book that I bought I think maybe four years ago. I read about half of it. And now at work I'm doing a lot more product development and product design stuff. So, I picked it up again. And it's just so, so good, lots of common sense stuff. Lots of if you've done usability testing before, it solidifies a lot of assumptions and things that you thought you knew, which is really nice to have that validation. But it's a really good book, really quick read, lots of diagrams. So, if you're interested in web usability and design stuff, definitely check that out.

Another one is F.lux which I think you may have heard of before. But it, I don't know if ‘dims’ is the right word. It changes the hue I guess of your computer screen as the day continues, which is really nice. Because it's a nice reminder, one to go to sleep [chuckles] if it's really late. But also it just makes it a lot easier on your eyes.

And I actually hooked it up to our Hue lights. So, Hue lights are LED lights that you can control from your phone. And we have all of your lights in our apartment, they're all LED lights. And so, we're able to hook up F.lux to that. So, not only do our computers dim and change based on the time of day, but our whole apartment does. So, as it's the evening it's a lot more soothing and comforting. And it's a nice reminder to go to sleep. So, I definitely recommend those tools if you don't already know about them. And those are my picks.

Awesome. Coraline, what are your picks?

My first pick is Madison Ruby 2015. I had the privilege of speaking at the conference this past weekend. Unfortunately it was the last time they're doing Madison Ruby which really breaks my heart because it's my absolute favorite conference. But they did use a company called Backflip video for recording all of the talks. And there's actually a live stream, recorded now, from both Friday and Saturday sessions on YouTube. So, you can watch everything that happened at Madison Ruby right from the comfort of your computer. So, I will link to those two videos, day one and day two, I the show notes. And I highly recommend it. There were so many great talks.

My second pick is a board game called 'Survive'. It's a cutthroat four-player game in which Atlantis is sinking and you must evacuate your people tokens to safety. You have to [inaudible] with sharks and whales and sea monsters as you get your people off of an island that's made of 40 randomly selected hex tiles. Every player controls 10 people that they try to move toward the safety of surrounding islands before the main island breaks up. The 30th edition version of the game is now available on Amazon. And it's a lot of fun. And I'll link to it in the show notes.

Very cool. I've got a couple of picks. The first one is just a reminder for Angular Remote Conf, if you're into AngularJS. Go check that out. It's my frontend framework of choice. And so yeah, I'm picking that.

They also had a conference up here in Salt Lake for React. And you're going to think, “Oh, so he's picking two frontend frameworks.” But React is pretty cool. And I got to meet some folks up there. I didn't actually go to the conference. I just took advantage of people being in town and drove up and met some folks for dinner. But yeah, so next year I'm pretty sure they're going to do it again. So keep an eye out for that.

Lastly, I've also been reading some books by Brandon Sanderson. I just decided since I liked everything he'd written that I'd read, I'd finish reading everything he'd written. And so, I've been listening to the Alcatraz books. And so, I'm now on the third book which is 'Alcatraz Versus the Knights of Crystallia'. The first one is 'Alcatraz Versus the Evil Librarians'. They are really, really fun books. Just hilarious. So, if you like that sense of humor and you like some of the other stuff that he's written, then go check them out.

And yeah, those are all the picks that I've got. So, one other thing I just want to throw out there is keep an eye out for Rails Remote Conf. I'm planning on doing that at the end of October. But I don't have the website up. Watch my Twitter feed for that. I've also been using Periscope. So, if you are interested in hearing me talk about podcasting or programming, then keep an eye out for information on that, too. And that'll also be on Twitter.

Thanks for coming, André.

ANDRÉ: Yeah, absolutely. Thanks for having me on.

It was great having you here, yeah.

ANDRÉ: Totally.

Yeah. So, if people want to contribute to Ruby Together, what do they do? Where do they go?

ANDRÉ: Our website is at RubyTogether.org. And if you're an individual Ruby developer there's a link right there on the home page that you can use to join as a member. And when you join, we'll send you an invite to the members Slack group chat. And we'll get you set up. And if you are representing a company, there's another link on the home page at RubyTogether.org that lets you see what the different company plans are. Companies that contribute more can get additional benefits like us shouting them out when we give talks at conferences and actually having a talk with them about their specific concerns as a company with Ruby infrastructure. And so, if you go to that page, you can see what the funding levels are and you can sign up right from there.

Alright. Well, thanks again for coming, talking to us about this. I think it's a really interesting way to support some of the things that we use every day.

ANDRÉ: Yeah, absolutely. I'm hopeful that it works and continues to grow and scale up as a model for making sure that open source gets worked on.

Yup.

ANDRÉ: Awesome.