The Changelog: Software Development, Open Source - Code for America (Interview)

Episode Date: July 26, 2011

Adam and Wynn caught up with Erik and Max, Fellows at Code for America to talk about civic-focused development and open source.

This week's episode is brought to you by Campaign Monitor. Campaign Monitor is an email marketing service for the discerning designer. With it, you can create and send beautiful email campaigns. You can track the results and manage your subscriber lists. Campaign Monitor's reporting and analytics tools go beyond opens and clicks. The entire application is rebrandable, which allows you to earn profits from the campaigns your clients run. You can check it out at campaignmonitor.com. Welcome to the ChangeLog episode 0.6.5. I'm Adam Stachowiak.

And I'm Winn Netherland. This is the ChangeLog. We cover what's fresh, new, and open source. If you found us on iTunes, we're also on the web at thechangelog.com. We're also up on GitHub. Head to github.com slash explore. You'll find some training repos, some feature repos from our blog, as well as the audio podcasts. If you're on Twitter, follow ChangeLogShow and me, Adam Stack.

And I'm Penguin, P-E-N-G-W-I-N-N. Fun episode this week. We talked to the guys over at Code for America, Eric Michaels-Ober and Max Ogden, about all of the things that they're doing at Code for America and also Rails Admin and some other open source projects they have going. This is a really fun conversation. I think that we've talked in and around this space for a while, everything from open government to

I think it's just the citizen coder is a really fun topic. Yeah, it's nice to see how you can apply your skills. This is kind of like a Peace Corps for coding, as Eric put it. You can apply your skills for civic good instead of just a paycheck. So just a paycheck. And they get to take care of a few cities, and they've got Tim O'Reilly's blessing on this thing too, so it's a fun little thing for them.

Yeah, get some momentum. Speaking of momentum, we're going to be at Lone Star RubyConf next month. Yeah. Doing a little design eye for the dev guy slash gal down there. So if you're going to be in Austin in August, come see us. Hope to meet you. Hope to meet you, yeah, for sure. If you're into the SaaS and the Compass thing on the front end,

that's what we'll be talking about towards the end of the topic. And also, quick little plug for the SaaS Way. Follow them on Twitter. The SaaS Way on Twitter. Fun episode this week. Should we get to it? Let's do it. We're chatting today with Eric Michaels-Ober and Max Ogden from Code for America. So guys, why don't you introduce yourselves and a little bit about what you do at Code for America.

Sure. I'm Eric Michaels-Ober, and I'm a Code for America fellow for 2011. And I write a lot of open source software, mostly Ruby. I'm Max Ogden. I'm in a very similar boat. I'm a fellow here in 2011 as well at Code for America, and I'm continuing to write a lot of open source software this year, mostly in JavaScript. So I take it you don't have to be a guide to write a lot of open source software this year, mostly in JavaScript. So I take it you don't have to be a guide to be a fellow.

What's a fellow over at Code for America? It's basically just a one-year position. It's a fellowship, so you have the opportunity to work. Code for America's main focus, like what we're all about, is basically being something like a Peace Corps or a Teach for America for Geeks. So it's like a service year. You basically get to spend a year giving back to society. And so we're working to help government make their, basically bringing open source technologies to government and making it more transparent through open data and open source software. What sort of projects are you doing? Is it city focused or is it anywhere? It's both. We're working with three cities this year. So Boston, Seattle, and Philadelphia. And

then there's also a project with the federal government that I'm working on. I could talk a little bit more about that if you like. Sure. So the project that I'm working on this year is with the federal government. We're working with the Department of Labor to basically build a website for veterans to try to help them find jobs as they come home from Iraq and Afghanistan. And it's basically pulling together a number of services from around the web that already exist in order to help veterans, but creating a veteran-friendly interface on top of those services. So we're actually using the LinkedIn Ruby gem that you created, Dwyn,

and LinkedIn is one of our partners as well as a number of other web services that are job-focused, job-related. So I know, Eric, you're a Ruby, yes, Max? What sort of languages are you slinging? So before Code for America, I was working at a rail shop up in Portland, Oregon, a market research company called Revelation. And it was a really good engineering team, but I was given the opportunity to kind of, like Eric said, almost take a year off and focus on a bunch of the stuff that was previously side projects for me. So at the time, I was getting really into CouchDB. There's like probably an inside joke around the office that anything that I do, I try to do on CouchDB.

It's like my hammer for every nail, but so far it's worked out pretty well. And as a result, I've kind of taken the deep dive into all the fun HTML5 stuff you can do because all couches is a persistence API for you to use, but you have to do all of the fun logic in the browser, which is a challenge, but

I've kind of not abandoned Rails and Ruby. I still like Ruby a lot, but I'm basically using Jeremy's underscore JS. I'm basically doing all the fun stuff I was doing in Ruby before, all the same paradigms, but trying to do it in the client side now and then getting into Node a bit. So I've gotten really into JavaScript the last year.

Jeremy, Ashkenaz's underscore JS. I think Jeremy is the new drinking game, so the Hamlin SaaS is going to be Ashkenaz. So there. I think Jeremy is the new drinking game. So the Hamill and Sass, it's going to be Ashkenaz. So there seems to be some doubt, Max, of whether or not you're on the market for employment looking at your GitHub page. I was on Isaac Schleuder from Joyent's page a couple weeks ago. And he has this thing that's like, recruiters go away, I'm happy at my job. And it has this occupation at Joyent, and he's like, I really like working here, don't ask me for other jobs. And there's so many recruiter emails lately that I copied him and put, no more recruiter emails, please.

So, yeah. So we've kind of gone into this a little bit, but not given a good description of exactly what Code for America is. It's ran for a couple years now, but what exactly is Code for America? So to give some clarity there. Yeah, this is actually the first year of the program. So it's a little bit of a startup and a little bit of an experiment about what it is. We're kind of figuring that out as we go. But basically, it's a service year program for geeks. So just like Doctors Without Borders, if you're a medical professional and you want to sort of spend a year working for good, there's a program for that. And up until Code for America came around last year, there was nothing like that.

If you were sort of civic-minded and worked in technology, there wasn't really a place for you to give back. And so Code for America offers a fellowship. There's 20 fellows. And next year there'll be even more. And applications are actually open now. So anyone who's interested in being a fellow, you get to spend basically all your time working on open source software. That's part of the mission and charter of our organization, that everything we do is released under an open source license. And we hack on a number of existing open source projects.

So it's a great way to sort of work on open source projects, give back, and just work with some really talented, brilliant engineers from all around the country to do good. The other half of that, I think, too, like what our mission is, is to try to test the water in this new kind of civic startup space. Our leader, Jen Palka, just gave a talk at the Future of Web Apps conference in Vegas and had some really interesting statistics on, like, take the size of the iPhone market.

It's something like $2 billion revenue a year. The government IT software market is on the order of hundreds of billions of dollars. So if we can tap into the software that's powering the country and make those pieces of software just as competitive as the startup market, it'll not only create a bunch of better software to run government and make the government work better, but it'll also allow people who are limited to making iPhone apps right now. You could actually make the software that's helping people find what potholes they should fill in at the city level. We're basically doing a lot of research

and development this year to try to figure out what are the areas that we can actually tap into and start improving using the same development processes that we're using in startup land. Who backs this? You said startups, so somebody must have gotten into this. I know we saw a couple names there at the footer that we see often. We had a couple shows already with the Knight Foundation, with Jeremy Oskan. I think that's kind of part of it as well. Who's behind Code for America?

We're not really an incubator, but we're like a more traditional nonprofit, I would say, from a funding standpoint. So it's about half grant funding and half city funding. So the city governments pay us and then we get a bunch of money from nonprofits and philanthropy. And like I said, our goal is to try to prototype out some of these new ways of using technology in a government context. I use the term startup, but we don't have startups. But probably a lot of the fellows this year are going to go on to continue working maybe in the startup space or working for governments doing this kind of work

in the future. You mentioned LinkedIn as a sponsor or a partner. I can't remember which way you said it. I think you said partner, right? Yeah. How does that play into companies like LinkedIn, Yahoo? I'm seeing some of the in-kind donors on your donors page. Are those the partners you're mentioning?

Yeah, the corporate world has been very generous to us. Cisco, as you mentioned, actually donated our office space to us. They made an acquisition last year and moved that company into their main headquarters. So they very generously donated that space to us. And a number of other partners, a number of other companies have made in-kind donations to us. Google has been very generous, especially their Summer of Code program. We actually have 10 Summer of Code interns here for the summer working on Civic apps and building open source libraries. So that's been a lot of fun.

I'm surprised to not see Crunchbase's name in your list considering one of your project's names. But it's not actually the name. It's Shortstack. It's not see Crunchbase's name in your list considering one of your project's names, but it's not actually the name. It's ShortStack. It's inspired by Crunchbase. What's that about? Sure. We thought it would be a good idea to basically have a repository

kind of like Crunchbase, inspired by Crunchbase, but for governments and government-related software so that if you're a city and you want to select some sort of software, you can see what other cities that are similar sized or maybe similar geography are using to solve that problem and reach out to them and ask them questions about it or help that navigate through your selection process.

I think it's kind of unique. I've had a number of desires to do something crunch-based-like for, like, Wynn and I have talked about doing something like that for the open source world, but if only we had just a year of Sundays, I think, right, Wynn? It's kind of a fun idea, though. So it's wiki-based, I'm assuming? It's wiki-based in the sense that anyone can update it and edit it

it's actually a Rails app on the back end you know we've worked I guess in the startup community and the open source community for a number of years and kind of in this echo chamber we speak APIs and mashups and JSON and REST architecture and things of that sort

what sort of environment do you find when you walk into these government and civic projects? Do you have to sell them on concepts that we already speak, or how does that work? That's a great question. You know, most city governments are sort of Microsoft shops,.NET shops, and most of them have outsourced the majority of their IT, and they just work with consultants. They don't have a large team in-house doing application development. And so coming from sort of San Francisco startup world, open source world, you know, you don't see a lot of Linux servers running Apache or Rails or anything like that.

So it's, you know, it's definitely a little bit of culture shock when we come into these governments. But our city partners, that's sort of what they signed up for. They, a lot of them, you know, cities right now are struggling to meet their financial obligations. And maybe they can't afford, you know, the big expensive databases and big expensive technologies that they've been paying for in the past. And so open source sort of meets that need of being very cost efficient. But the problem is they just don't have the in-house expertise to bring those solutions to bear for their citizens.

So that's sort of what we come in and do and sort of show them the ropes and teach them how to deploy these services in their city to make a better, cheaper solution for their citizens. Earlier today, actually, we had a really awesome lunchtime speaker, Carl Malamud, who does public.resource.org. And Carl's original claim to fame was in the open government world. It was back in 1994. He got a grant, something like $30,000, to buy the SEC filing database that they were selling on a subscription basis. And then he just

took one license of the data and then put it up online so everybody could see the SEC filings. And since then, he's been like blazing a trail of taking huge data sets and making them available. And he really, I think, really eloquently illustrated a good model, which is any government that wants to build something that people are going to use should do it in three steps in this order. Put all the bulk

data up online so that anybody can have access to bulk, raw information, developer-centric information. Then refine it into an API and try to make the data useful, and then build your website on top of that API and dog food the API. And really do it the complete opposite way that a lot of vendors, giant software vendors and the government are doing it right now, which is we're going to build you a website,

and then if enough people complain to you about not having access to the information, maybe we'll build an API later, but you're not going to be able to get the bulk data out of it. And that's just one example of like an approach we're trying to like flip on its head in a bunch of the work that we're doing. And that's assuming that the government has digital data that is interesting to people. And a lot of our projects are like, we'll show up at City Hall somewhere and say, oh, well, you must have a database of every pothole that's been, like, complained about in the city with a map, right? Like, that's an obvious. And then sometimes they're like, oh, no, actually, they're, like, locked, like, they're on paper, or they're on another database in another

building, or there's no way to get it out. Or sometimes they do have it and it's not made available, and then that's a really kind of juicy scenario where we can take that and then turn it into a public API that a bunch of people can build, see how many potholes are reported in your neighborhood, or go fill in a pothole because the city is too busy to get to it, or any of these sort of applications. And I think it's really awesome when we can find data that's already there, but one of the things we're having a lot of fun with this year

is figuring out how we can generate data that the government doesn't have time or money to collect because sometimes the Venn diagram doesn't overlap of things the government's collecting and things that are interesting to people, but if the data were to get collected, it would be really helpful for the government for analytics, and it would also be really interesting to people

and boost citizen engagement in different areas. So we're looking at things like Ushahidi for doing crowdsourcing, that style of getting people to help out to build a data set. That's just fascinating. We talked to the Sunlight Foundation folks, and they had this concept of a citizen coder, and you mentioned consultants and kind of the entrenched consultant world. Do you think this concept of a citizen coder is on the rise?

And does your organization kind of foster that? Yeah, we hope so. I mean, one of the things we want to do is take government data that's, you know, hidden in this either proprietary formats or in some database that nobody has access to or knows where it is or just hasn't been digitized and take that, get it up on the web, make APIs for it, give people access to it so they can be citizen coders if they want to. The first sort of step in enabling that is having the government's participation. And all this data, almost by definition, is public data. It's data that has been paid for by the taxpayers and should be public. There's no sort

of reason or justification for keeping it behind closed doors other than either nobody's asked for it or technical incompetence. And so we try to solve both those problems. I think there's something like 30,000 municipalities in the United States, maybe more. I don't know the number off the top of my head. Some huge number like that, right? And we're working in three of them. They're bigger ones. But there's so many smaller multi-thousand people, 10, 20, 50,000 people's cities around the country. And you forget about all the data we're getting and you just look at our GitHub projects, for instance. If you go to github.com slash codeforamerica

I think there's like 100 plus repositories on there. They're either things we've forked or things that we've made to solve different problems. Any of you listening out there in, let's say, the Midwest, in your, take one of our projects and clone it, change the title from the Boston fire hydrant mapper to the Kansas City, Missouri fire future years of Code for America is make it super actionable for a single developer living in a city that doesn't have any of this fancy stuff, any of this fancy government technology that we're making. Like, making it really easy to clone a project and stand it up and start, like, peddling it around the city. Go and talk to your, like, community groups to start using this stuff. We want to really, like, kind of kickstart some of this citizen engagement stuff, so you can just have a single developer set up a project

and then have all the tools that he needs to really get his community involved in it. Because we can solve the problem in a bunch of big cities, but I don't think that we'll be as successful if we don't get a bunch of, like the huge long tail of all the small cities working on this stuff. So there's a lot of opportunity. All it takes is one person in one city. So you guys are in San Francisco, right? Yeah. And one of the states we hear a lot about with government, especially with budgetary things and deficit and stuff like that. And you mentioned one of the biggest things with government

is just meeting their revenue needs and having enough money to go around to take care of the technology that they have to do their jobs, I guess. You guys are in San Francisco, but I see Boston, Washington, Philadelphia, and Seattle on your list. Why not Cali? Like I said earlier, this was our first year, and we only have 20 fellows, and we sort of wanted to get a sort of select diverse group of cities from all across the country. And we might be working with some cities in California next year, but our headquarters is in San Francisco, and we think that makes sense for sort of being at the hub of technology. But we want to work all across the United States. And next year, we're going to be expanding the number of cities that we're working in

all across the country, including smaller cities. So, for example, Macon, Georgia is going to be one of the cities we're working with next year, which I'm guessing most of your listeners have never even heard of or don't know quite where that is. I don't actually know, Megan. Not me either. So what is the selection process for the cities then? So the cities can apply to be a code for America City.

And there's a proposal process that's actually closed now. But we go through the city selection process each year and come up with a list of cities that we think have sort of have the right people to be a little more experimental and try the Code for America model and also who have an interesting project, something ambitious, but also that we can take a pretty good crack at in one year because that's the length of the fellowship. The other half, too, is you don't necessarily need a city's involvement with us for us to have impact. There's a whole spinoff organization between us and a group called Open Plans called Civic Commons. And Civic Commons is, the way that I describe it,

is going to take all the Code for America projects and any other projects that we can get that fit a similar pattern and just, like, spread them around to every other city. So, for instance, if we go into Seattle and we build something that allows Seattle neighborhoods to talk to each other better, it's not like no other city in the United States has neighborhoods that need to communicate inside of their neighborhoods better. We're really trying to pick.

When a city applies to our program, we look at their problem and say, how universal of a problem is this? And most of the time, they're pretty universal problems. Every city could benefit from them. But at the same time, having somebody on the ground in a city to really integrate the technical solution into the context of the community is really powerful, too. So like I was mentioning earlier, you have to have some software there because Rome wasn't built in a day. But we can't just copy-paste Rome between all these different cities. We need to have somebody, like a team, on the ground.

But you don't necessarily need the city's involvement to do these things. We're not in San Francisco city government, but because we're physically in SOMA, we've met with the innovation director, Jay Nath, at the city of San Francisco.

For instance, I was in a meeting with the art director for the city of San Francisco that we just did on a Friday one time. Jay and I and another fellow, Anna, a meeting with the art director for the city of San Francisco that we just, like, did on a Friday one time. Jay and I and another fellow, Anna, went over to the art director, his office, and got all of the art data for the city. So every location of every statue and, like, public mural that the city has commissioned, and we're putting it into a mobile app and an API that people can help improve the city's art database. And then similarly, Oakland, right across the bay, we went over there and they ran this event called Code for Oakland. That was the first time that

the city had ever taken any data and said, hey, anybody that lives in Oakland, come and work with our data and see if there's anything cool you can build. And one of the projects that came out of that that I've been working on is a big wiki for social services, like homeless shelters. And Oakland specifically has a lot of reentry programs. When you get out of jail and you need to basically rebuild your life, their government tries to help out a lot with that. But as you can imagine, the government websites for finding out about these services are really bad. So we're trying to take the data and then put it into a really appealing set of APIs that we're going to try to get a bunch of people in different cities to go around and fill out these databases of where all the homeless shelters are,

where all the food stamps offices are, and make them really actionable. So that's all stuff that's happened just by virtue of us being in physical proximity to these cities in the Bay Area. And I think that as more time goes on, hopefully more little projects pop up because somebody saw a really cool concept on one of our GitHub projects or something. And they said, whoa, there's a big opportunity in the city that I live in. Like, I'm just going to start going around and seeing if there's any interest. I'd like to switch gears for a minute and talk about the personal angle here. So Eric, having worked with you to use the word prolific

would be a massive understatement. And looking at your page, you, to use the word prolific would be a massive understatement. And looking at your page, Max, I think the same would be true. What does it mean career-wise to pursue this sort of position? I think we had visions of grandeur 10 years ago, thinking we had to move out to the Valley and make a lot of money as a developer. But getting to code on open source can be just as, not more rewarding what's it meant to you personally yeah it's incredibly rewarding i mean being a code for america fellow is definitely a pay cut for just about any developer but that's not why you do it right and it's been being a being a part of the open source community, being able to sort of,

you know, contribute, like work on projects and go to conferences and have other people who I know and respect use those projects that contribute back to them. It's just an incredibly rewarding experience. And I think, you know, sort of no matter what I do next that's always going to be a part of what I do because it's important to me. Code for America is basically a chance to go all out on that and spend a year just really focused on open source. There's not a lot of jobs, unless you're a Yehuda Katz or someone like that, who,

uh, it's really hard to, to find a job where you get paid to write open source software and, uh, Code for America, you know, you don't get paid that much, but, but again, you, you get the, the benefits of doing it, um, it, you know, in the community. And, uh, yeah, I think sort of my, my career prospects going forward are, um, I'm, I'm prospects going forward are I'm very satisfied with the career move, you know, taking a year off to do Code for America. It's been one of the best experiences of my life. And I also just while we're talking about it would mention that the deadline to apply for Code for America is coming up real soon. It's July 31st. And the URL to do that is codeforamerica.org slash apply.

So I'd encourage anyone listening who's interested in it. It's been a great experience for me. And the application doesn't take too long to fill out. So go do that before the deadline. I think Wynn and I can both echo kind of what you said there with working on something that gives you that feel-good feeling. It's nice to make money, but at the same time, it's really nice to honor your blessings and your talents and do something that is good for humankind in general in whatever way you see fit. I actually listened to one of the YouTube videos. Carla Macedo, I think is how you say her name massito yeah that's a great video about yeah she talked

about you know just being able to i mean it's like a it's an opportunity of a lifetime really i mean you get to be chosen out of i don't know how many get selected but or apply but i mean it's it's really a cool thing but uh and had mentioned, your GitHub profile is not lacking. One of the projects we've actually been eyeing up on on your profile, Eric, is Rails Admin. Have you made any use of that or progressed that in any capacity as part of working with Code for America? Yeah, it's been growing incredibly fast.

So for those who don't know, Rails Admin is basically an automatic admin interface. Originally, I started developing it as Merb Admin. I was a big Merb hacker back in the day. But then Merb and Rails merged into Rails 3, and as part of the Ruby Summer of Code, I actually mentored Bogdan Gaza, who's a Ruby Summer of Code intern, to basically port over Merb Admin to Rails 3.

And that project's just taken off. I think it has over 2,000 watchers on GitHub. And it's basically just a really easy interface that anyone can use to edit data. So basically just the crud of crud applications that you'd perform to any database table. There's a nice, easy UI on top of that, and we're definitely using that in Code for America projects,

and I've had a chance to develop that further as a Code for America fellow. I like how open source gets to circle back and feel this too. Some of the initiatives you guys are working on, just what it says is codeforamerica.org issues is openness, participation, education, and efficiency. We're all in this open source world. We get to contribute a small sliver of a fraction

of what is in open source. But it's nice to see that come back in and still be used and probably get you up and running pretty quickly too. I just actually made a graph on the new GitHub API, the v3 API of the last year, the last 12 months of my life and what the number of projects that I've had, like my activity on GitHub, just as an experiment to see. And last OSCON, last July, so about a

year ago exactly, Tim O'Reilly actually recruited me, basically, and I got really excited about Code for America. I was still working at the startup I was at for another, like, four or five months, but then left to come down to San Francisco around December. But from July, in July I had, like, nine GitHub repositories. But then as soon as July hit, like, now I'm at, like, 97 or something, and it was just, like chart just like skyrocketed. And I remember like, I, I had like a nine to five and then I would get off work and go in Portland to coffee shops until like nine or 10 or 11. And I was just like totally excited and like super pumped about all of this stuff in this space. And a lot of the projects I work on are, uh, like data driven, uh, two of the big themes, I would say, are getting people out in a community,

taking photos of funny things and putting them on maps. I come back to that concept a lot. And I started with mapping smells in a city and making a big what smells are where. And then I got into mapping feral cats and then mapping food trucks in Portland. And then now I'm mapping homeless shelters and trying to, you know,

like expand upon all of these mapping things. But then the other stuff that I'm working on, which isn't necessarily code for America related, but I would say still like philosophically it's in the same category is like identity and privacy and social network user centric. The whole like there's a really great podcast that Brendan Eich did yesterday on A Minute with Brendan.com where he talks about Mozilla's new strategy for we put the user first, and that's, like, hit the nail on the head

of all the stuff that I'm really passionate about. So being in an environment that's trying to solve the problem of I'm a citizen in a city, how do I get more hooked hooked into the way that my community is working? I heard somebody describe government as a tool that exists to foster communities. That should be the goal of a civic local government. All it should do is make sure that your communities blossom. And I totally believe in that definition. But either if you're a user online using Facebook, or you're a user online trying to like file your taxes, or you're a user online trying to like talk to somebody in line while you're waiting at the coffee shop.

I'm really interested in like user-centric design and like what software allows people to do. And I'm totally, it's like consumed my life the last year. It's kind of crazy. Like GitHub is definitely an addiction for me lately. We're definitely in the Generation G, right, Wynn? That's true. So, Eric, a number of your projects that you're actively working on aren't really your projects. And I know I'm thankful that you've pitched in on a few of mine where I've started an idea and

haven't pushed it as far as I think you and others in the community have. What sort of satisfaction do you get from, I guess, working on somebody else's project? Well, I think there's a big tendency among engineers to look at somebody else's code and sort of get frustrated with it, with some aspect of it, and want to just reinvent the wheel from scratch. I think one of the great things about GitHub is that it makes it so easy to look at somebody else's code that maybe you think you could improve

and actually make it better rather than trying to fork it and compete with it. And so there's nothing wrong with healthy competition if two projects have different goals in mind. But if you're fundamentally trying to do the same thing, then my philosophy is don't reinvent the wheel. And so a win, I think the first project we ever collaborated on was actually John Newnemaker's Twitter gem.

That's right. Which he had built and then sort of moved on to working on MongoMapper and God knows what else he works on. He has quite the open source resume as well. But he wasn't investing a lot of time in the Twitter gem and he had sort of handed it over to you. And I was working on a startup called 140 Proof at the time, which was a Twitter startup. We used the Twitter API heavily, and we needed a Ruby library to interface with Twitter.

And I think it started with, I just wanted to make some enhancement to the Twitter gem. It, I think, didn't upload images correctly. And, you know, we wanted to be able to update someone's profile icon or background wallpaper programmatically, and that wasn't supported in the Twitter gem. So I think the first patch to it I ever made was adding sort of the ability to do a multi-part post to the Twitter API via the Twitter Ruby gem. And then from there, just kind of like Max said, just kind of got addicted to making improvements to it and polishing things off.

The biggest conversion was switching over from John Nunemaker's HTTP party as the HTTP client library, switching that over to Faraday, which is kind of like a meta HTTP client library. So you can use NetHTTP or Typhius or EM Synchrony if you're on a vent machine. So that seems like a refactor worth doing because people wanted to be able to swap in their favorite client library.

And then I just sort of started moving up the stack. So the more I got into Faraday, the more I wanted to make some changes there and became a core team member of Faraday and started making some contributions to that. And that's basically been most of my open source. That's TechnoWini. Rick Olson's project started it, and now Mislav, also at GitHub, does a lot of work on that project as well,

but more than probably Rick does these days. But it's another great open source project that, again, could have tried to reinvent the wheel and start from scratch and do my own thing, but it just seemed like it was there and it was sort of good enough, a good enough foundation to make better. So that's sort of my philosophy on open source in general. It's all about that community and that collaboration

and working with other people. A tech book that had an impact on me a few years ago was Leading Geeks by Paul Glenn. He talks about how, as a group, we geeks kind of buck the normal power structure and we all gravitate to the alpha geek in the room. And I think that's why I love GitHub so much is it automates that process. It's easy just by looking at open code

that's out there to see who's got a better grasp of the language or techniques and things like that. And we kind of all go through this progression of cargo culting to imitation to, you know, then kind of thinking on our own and being creative about it. I've learned an incredible amount just from looking at other people's code on GitHub. Who are you guys learning from on GitHub these days? Oh, man, so drinking games. So Jeremy, I remember I was working at this company, Revelation,

and my boss, Dan Herrera, he's Wobot on Twitter, he was telling me that he found this book, How to Write Your Own Freaking Awesome Programming Language. And he was saying it talks about lexers and parsers and ASTs, and it was this really interesting and really approachable way of getting into language design. And I guess Jeremy read that book and then wrote CoffeeScript as an implementation of the things that he learned in

that book. So if you go to the really early days of the CoffeeScript repository, it's really fascinating to look and see how the language was evolving back then. And just his style is really cool. And I love the kind of temporal aspect of GitHub in that way. You can go back and see that it started from nothing and he just sort of started adding things and it really grew and blossomed from the ground up and it demystifies this prolific programmer thing. It's like, I don't think that you have to be a genius or some sort of whiz kid to be a really active developer

or have a successful like open source quote unquote presence. It's just like it's time and it's dedication, and you really just have to like have the ability to follow through with starting something. So one of my favorite things to do on projects is to go to the very beginning of the commits and just read the commits from the beginning and going forward um and i also i'm a big fan of uh like http apis for everything um you know that meme the like all the things meme with the little cartoon character with his arms in the air like blank all the things um i made one last week that was rest api for all the things and i think that uh like eric was Eric was saying with Faraday and some of these HTTP libraries,

it's funny that after 20 years of having HTTP libraries or more than that, they're still really bad in my opinion. It's a really hard thing. There's all these abstractions on top of HTTP libraries. And I've been having a lot of fun, like, looking at the ways that different languages do HTTP and which ones have their own weird abstractions on top and which ones are really minimal.

And one of my favorite ones is in Node by Michael Rogers. It's just called Request. And it's Michael, M-I-K-E-A-L, Michael slash request. And it's just, like, the most straightforward HTTP library you'd ever use. And when I was learning CouchDB, I was like, oh, it's full HTTP. I better go find a

Couch client library to use with Node or from JavaScript. And I was like, there has to be some really great library that's designed specifically for Couch that does all the HTTP stuff. I actually found out that Request was the best library to use, and you won't find the word Couch anywhere in the Request source code. It was just like it implemented HTTP really well.

So there's always these gems, no pun intended, that are just like they make a protocol like HTTP really easy to use and just make it really nice. And I love when I find systems that just like both implement the same contract together. And they, you know, you have like the request library in CouchDB as an example, they don't know anything about each other, but they work better than anything, anything else. Anyway, that was kind of a tangent. No, good stuff. Eric, you mentioned a couple of folks, anybody else you'd want to highlight? Oh, yeah, there's so many people, so many great people in the community.

I really enjoyed the podcast you guys did last week with Sam Stevenson. I have so much respect for that guy. And after listening to it, I just dove in on some of his projects just to check out the code. And, yes, Sam's awesome. Really enjoyed that interview. Also, the Rubinius guys, specifically Brian Ford and Evan, I just think Rubinius is an awesome project and have a lot of respect for those guys as well and the work that they're doing.

There's so many great people in the open source community like that who, you know, you sort of follow them for a while and then, you know, you don't really know what they're like in person and then meet them at a conference and they're just like super down to earth and will answer all your questions and really nice people. You know, I put Jeremy in that category as well. So, that's great. You know, for me, that's really, really the most rewarding thing about working in open sources is the people, you know, just being able to work with

so many talented people as peers. And, you know, you contribute to their projects. And if you're lucky, they accept your patches. And, you know, maybe if you're really lucky they'll start contributing to yours and there's just sort of that give and take component to it that there's nothing like it. For me it really is an addiction. One of the things that I like about this community is we tend to talk in projects and usernames and logins and not so much the real names behind a lot of these projects. And I know that I've been at conferences,

and, for instance, one of the guys that helps us with the Twitter gem introduced himself to me at South by Southwest as Steve Reichert. And I just kind of looked puzzled, and he said, Laser Lemon. Oh, Laser Lemon, right? So it's just this whole community around, you know, where the projects are almost as big as the personalities behind them. Yeah, and I definitely give a big shout out to Steve. He came in right as we were about to release 1.0 of that gem

and really just completely rewrote some of the interfaces, refactored them, and made them much, much nicer so that we could have a really solid 1.0. And he's also, he works on a number of interesting projects, including the Simple OAuth gem, which is like the best gem for doing OAuth and Ruby. And he also blogs for Collective Idea, where he works. And I'd highly recommend subscribing to that blog. He writes some really interesting stuff. So yeah, definitely.

Shout out to Steve. One last thing before we get to the radar. I know that you've been a proponent of folks not needing to know how to code to contribute to open source. What are some other ways that folks can get involved? Yeah, definitely. So I actually gave a talk on that at RedDirt RubyConf, which we both attended.

And on almost every repository that I'm active on, I talk about the ways that different people can contribute. Because I want to set the barrier to entry really low, because I think writing open source code is sort of this addictive thing. And once you kind of get your foot in the door and get over that initial hurdle of intimidation, like there's a lot of ways that people can get involved. And so with Rails Admin, for example, there's over 100 contributors on that project. And one of my favorite ways for people to contribute without knowing how to code at all is just translating it into a different language. And I think Rails Admin now has been translated into 15 or 20 different languages all over the world.

So that's a great thing for someone to come in and do. And it really helps. Like, people are using it all over the world, and it's great to see that. Just, like, using alpha and beta and pre-release versions of software is helpful, and reporting bugs and issues is great. You know, suggesting new features, writing documentation, editing existing documentation. God knows there's tons of typos in open source software documentation all over the place. And it's just not well written. A lot of programmers aren't as great at writing prose as they are at writing code.

And somebody with an English background can come in and make a lot of progress there. You know, also just like really small fixes, just like setting the bar really low in your project. Like I always say, you know, a patch, I'll always accept patches that add documentation, add comments, clean up inconsistent white space, alphabetize things that are sort of out of order, or just neat and things up. For me, those are some of my favorite patches to receive because they're often from people who've never contributed to open source before, and it is that visceral feeling of contributing in the way that they can

and at the level that they feel comfortable doing. Or just removing white space. Yeah, just removing whitespace. Honestly, as a Vim user, I'm used to jumping between code blocks with shift bracket, like open bracket and close bracket. And I think it's TextMate, but one of the editors is terrible about

if there's an empty line, it indents it to the level of the previous line even though there there's nothing on that line like there's no reason for it to be indented and that actually breaks um that breaks uh workflow for a lot of vim users and it also like git doesn't like it like it'll highlight it and um make it kind of uh like like it'll show up as highlighted and and get when you try to commit it. So just pulling that stuff out is, it's a great contribution. It's like a little thing that you can do that makes it a little bit better for everyone who's using it.

And that's what open source is all about. I think it actually might be TextMate that does that. Because I know that whenever I do a return from a new line, it's indented. It goes to the start point of the previous line. Yeah, and for people who want to keep using TextMate and not piss off Vim users, there's actually a TextMate

plugin. Maybe you can put it in the show notes, but there's a TextMate before save hook that will go through and clean up all of the terrible white space and indentation that TextMate inserts. So honestly, just doing that is a big...

If everyone listening to this who uses TextMate just did that, that would be a big contribution to the open source community. Especially if you commit to open source. Yeah, that's right. If you're just doing your own code. Well, but even at work or whatever, I think, you know, just writing, you know, it's sort of like the postal principle of, you know, kind of writing code that kind of could be accepted by the most editors or whatever.

It, like, won't break parsing in the most editors. There's just little things like that that you can do that are a little bit just considerate of other developers. A good practice to follow. One of the things that's really fun this year at Code for America is that we have open source projects, but the target audience

for a lot of them isn't just developers, it's also users or people who are going to stand them up in different cities. So it's really interesting to say, okay, we have GitHub. How is GitHub going to be our way of managing people who aren't even programmers or even, like, working with designers? And I think that, like, the new GitHub for Mac app

is really cool from the, like, eliminating the command line for people who have never been on the command line anymore. They can still have, they can still take can still take part in distributed version control workflows. And the GitHub image diffs are really cool. I was talking with Tom Preston Werner, TP Devs from GitHub, about there's this guy who gave this presentation. We were both there about these mechanical, every piece of machinery you can imagine to run a farm.

He's been designing open source versions of these systems. So you could download the schematics for a tractor and then build it for as cheaply as possible. And he's trying to build like 100 machines, 100 open source machine templates. And so he has a lot of 3D models. And he's talking to Tom about like, hey, how do I do 3D models on GitHub?

When are you going to implement that feature? And then Tom was like, well, we could do WebGL rendering. And it's really exciting stuff. The idea that it's not just code anymore. It's going to be any sort of, we have a file that we want to collaborate on and use GitHub as the hub for that. I was reading this book by Ted Nelson, the dude that invented hypertext back in the day. And it's called Literary Machines. It's really hard to find for whatever reason, even though it's like the book about the Internet before the Internet. And he was describing in Literary Machines

what he thought the Internet was going to be back before we had the Internet. And it was like, well, everybody's going to have their version of a document, and if they make changes to it, they could submit it into the repository, and you could see all the forks that somebody, he didn't use any of these terminologies, but you could see all the forks that somebody's made. And everybody will be able to collaborate on editing things. And it's like, here we are 30 years after that book was written. And what do we have to show for it?

We have Wikipedia, which is like its own universe. And then we have GitHub. There's been many source control platforms over the years, of course. Not to discredit any of them, but I think GitHub has really hit the nail on the head in terms of actually like realizing this vision of like, let's just make information into this thing that we can all help to build. And it's really, it's a really exciting time,

like imagining the uses of this technology for things other than just code. And from a Code for America standpoint, like with the open211.org project that I'm working on, we contacted, I did a whois on open211.org. It was taken. I contacted the woman who was in charge of it. I sent her an email. I'm like, hey, we're Code for America.

We're this nonprofit trying to build a big wiki of all of the homeless shelters, basically. And she was like, oh my God, I saw Tim O'Reilly give a talk about this once. I love you guys. Like, have the domain. I'm transferring it to you right, oh my God, I saw Tim O'Reilly give a talk about this once. I love you guys. Like, have the domain. I'm transferring it to you right now. What else can I do to help?

And I'm like, well, go to GitHub and make an account and then use the fork and edit button and just like clean up any of our copy. Like there's, if you go to open211.org, it's supposed to be a page that describes the project. And I have like a few months ago realized that I should be making screencasts about every project that I do. I should

be doing readme-driven development. I should try to make every project that I do as much of a template for other people to either take and reuse in some other domain, or to just make it really easy for people to get involved. This woman actually made a GitHub account and was able to

fork and edit our readme, which is really cool. I think the tools are coming a long way. Google Code has had the fork and edit feature in browser for a while. It's just bridging the gap from developer. Every startup that starts up nowadays, I'll look at it and be like, well, are those things that developers could do 20 years ago that now only we're getting around to making it accessible to every person? And that's a really fun

game to play. So there's IRC Cloud now, which is IRC without having to know how to run a screen session. Or even you could argue that Twitter is IRC for everybody. Or there's all these things that we never build for people that aren't developers, but it's not that non-developers aren't know there's like all these things that we never we never build

for people that aren't developers but it's not that non-developers aren't nerdy enough to do these kind of like distributed

editing things it's just that anyway what I'm getting at is it's a really exciting time I had that aha moment today

too before I got on the call whenever I jumped on the Code for America org on GitHub I was like wow

118 repos 51 members like this is the epicenter of everything that you guys are doing, revolving around your code bases and your projects. This is, you know, this is, I mean, this is the, if you had to say a deliverable, this is the deliverable pretty much until you actually get to production, but it's, it's pretty wild, but we're almost out of time.

So the last question I'd like to ask is about what's fun in your world with open source? What are you playing with? Max, I know you said you're a big fan of CouchDB, and Michael, you'd mentioned that you're Rubyist, so I imagine that those are probably camps you like to play out in, but if you had to venture out of that camp, what is something fun that you might want to play with in open source?

I've been playing around with Socket.io a little bit recently on Node, and that seems really cool. It seems like something that was, kind of like Max said, something that would have been pretty hard to do just a few years ago, but now it's becoming mainstream and it's going to enable a lot of new products and new technologies. That's kind of my little hobby project these days. I also, this is within the Ruby realm, but I think one sort of way to be a good open source citizen, especially if you're doing library development, is to test your library across multiple different versions of Ruby. And the best way, easiest way I found to do that is to use Travis CI.

So I definitely want to give those guys a plug. It's a great product. It's still new, and there's still some bugs in it. But it's incredibly easy to get set up. And basically with one YAML file, have free hosted continuous integration for your project on JRuby, Rubinius, 187, 192. And that way, you know, when you do development, you don't want to run your tests n times once for each Ruby, but you want to make sure that it's compatible with every Ruby out there so that the most people can use it as possible. And that's been an invaluable tool for all the Ruby libraries that I work on.

I've been bugging Josh and those guys to come on the show, and they keep saying when we get to 1.0, I told them now that they're building Rails nightly, they have to come on. So there will be a future episode. It's cool. I've been doing a little bit of hacking on GemCutter as well, the rubygems.org site, which is an awesome Rails app.

I would say if people are looking for a high-profile project that they want to work on, Rails project, we're working on getting that up and running on Rails 3.1. Right now it's on Rails 3.0. And there's just a bunch of features that you could add there. It's like someone wants to

earn their chops using a high-scale, high-visibility Rails app, submit some patches to rubygems.org because that's a great project. We just got that up and running on Travis last night as well. Travis is great because there's no way I'm going to be running. Even with RVM, I'm not going to test my test suite against Ruby Enterprise and JRuby and the whole nine yards.

I'll let Travis do that heavy lifting. Exactly. Some of the stuff I'm excited about lately, like two weeks ago I found this repository called Substance. And it's by Michael on GitHub. I'm not going to try to pronounce his last name. He's a Belgian. Sounds like Michael needs to come on the show. He's a Belgian. Sounds like Michael needs to come on the show. He's amazing. Michael, just like the normal way you spell Michael on GitHub,

they're at this place called QuasiParticle, which is like an Austrian software development shop. He has some of the best projects that I've seen in a while. Basically, it's like an HTML5-based document editor, not unlike something like Google Docs or like a WYSIWYG editor, but it has this really cool, like he has this thing called data.js

that's a persistence layer. So anytime you type in a document into the editor, it's persisting it into a graph document format in JSON in your browser. And then he has like a replicator that replicates the CouchDB, which I really liked that part. But basically, he's trying to build this really amazing suite

of all GPL or MIT-licensed editing tools that are just really, really well-designed. I was really blown away by the quality of the work that he's doing. And so I was talking with him online the other day. I'm like, wow, this is really cool stuff. I've been coming at a lot of these problems from a structured data standpoint of, how do we make data better? How do you clean up data? But he's coming from the qualitative, unstructured data standpoint of how do we make

document authoring really easy and build an HTML, JavaScript, HTML5 WYSIWYG editor that doesn't suck. And I don't know. I just got really jazzed by the amount of design skills that he has, and a lot of his theories on data were really cool. Another really amazing set of projects that I saw, Substack in the Node.js community. Isaac, who does NPM in Node, called Substack the why of JavaScript. Why the lucky stiff.

And why the lucky stiff was actually the guy that got me excited about programming in a kind of artistic way in my spare time. And Substack, his name is James Halliday. He has a startup called Browserling. And if you go to browserling.com or you go to Substack on GitHub and you look at any of the repositories from the last few months, every single one has a hand-animated character that represents the repository.

And the other day I was using, he has this thing that you can convert a node module, server-side JavaScript, into a requireable module for client-side JavaScript called Browserify. And you click on the repo and it's like there's a Harry Potter, a hand-drawn Harry Potter character in the repository. It has nothing to do with browser-defined anything. But I sent him a pull request because I added an example into the readme, and

I used... He was making a Voldemort reference, and he was like, Voldemort is to JavaScript as common JS. I don't know. It was this crazy awesome thing, but now he's going to add a Voldemort character to his repo. But if you go to browserling.com, it's all hand-animated by him,

and it's like a cross-environment browser testing tool that you can test your website in different browsers. But all the UI is hand-animated. It's amazing. It's a totally labor of love. He's a very prolific programmer, too. So fork some of his projects and add animations. Good stuff. Wow.

I think that about wraps it up. I know that we certainly appreciate you guys taking the time to come on the show and give us a peek behind the veil of Code for America and the great stuff that you're doing for civic communities and our cities out there. I know we certainly appreciate you taking the time out of your careers to do

that, whether it's great for you in your future or if it's just a year of wild coding or whatnot. But we certainly appreciate the time you've given us today. Great. Thanks for having us on. We really appreciate it. And I'm going to plug the Code for America Fellowship one more time. The deadline to apply is July 31st. So go to CodeForAmerica.org slash apply and check it out

do it, do it now we'll definitely put that in the show notes thank you guys