The Changelog: Software Development, Open Source - Better GitHub Issues with HuBoard (Interview)

Episode Date: January 16, 2015

Adam and Jerod talk with Ryan built about HuBoard - a project management solution for teams and organizations using GitHub. He gives us an inside look at how he created HuBoard, how he made the transition from free service to paid users, the technical challenges of getting set up to handle enterprise, and more.

Welcome back, everybody. This is the Change Log, and I'm your host, Adam Stachowiak. This is episode 137, and today, Jared and I talk to Ryan Rau, the maker of HueBoard. HueBoard is a comp on board for GitHub Issues. Fun conversation today with Ryan about open source, licensing, taking contributions, building his business on top of somebody else's business, GitHub Issues,

their API. A lot of fun conversation. We have some awesome sponsors to mention for this show today. CodeShip, TopTile, and DigitalOcean. We'll tell you a bit more about TopTile and DigitalOcean later in the show, but our friends at CodeShip, big shout out to them because they just launched a brand new design. It looks beautiful, by the way. CodeShip is a hosted continuous deployment

service that just works. You can easily set up continuous integration for your application in just a few steps and automatically deploy your code when all your tests pass. CodeShip has great Thank you. or even your own servers. Setup takes just three minutes, so you can get started today with their free plan and make sure you use the code, TheChangeLogPodcast, to get a 20% discount for three months on any plan you choose. Again, that code is TheChangeLogPodcast. Make sure you use that code.

Head to CodeShip.com slash TheChangeLog, tell them you sent you, and now on to the show. What's up, everybody? We are back. This is Jared with the changelog. Got Adam Stack in the house. Adam, what's up?

Adam Stack. Yes, that's me. Woo-hoo! And we're joined today by Ryan Rau with Hubor.com. Ryan's a guy we met down at Keep Ruby Weird in the fall. I enjoyed talking to him, and we're interested in what he was up to with this open source product. Ryan, how you doing? I'm doing well. Thanks for having me, guys.

Austin, Texas, man. ATX in the house. ATX, but you're not from ATX. No, I'm... Cornfields. Yeah, I'm originally from northeast Iowa. Northeast. Teeny tiny town called Cresco.

Okay. Yeah. My hometown butts up to the Iowegians. Iowegians. But that's on the west side, on the west side of Iowa. I've never heard that before, Iowegians. You're from the great state of Nebraska? That's right.

Omaha. But I've drove through there a few times. It's pretty fun to go 95 plus on I-70. Yeah, not much to see, but you can definitely drive fast because there aren't too many folks around either. Right. So, Ryan, tell us about HueBoard. So what is HueBoard?

What does it do? You know, I get asked this all the time, and I keep trying to refine it. When I first launched it, it was GitHub issues made awesome. But I've been trying to better describe it as it's really like a project management solution for teams and or GitHub organizations. The reason I say that is because we don't really just deal with GitHub issues anymore. We've added some features around linking repos together so you can have this holistic view of your entire project. So you can link repos together and you can also manage milestones across multiple repos,

which was kind of a challenge to implement as well. So it's kind of broadened in scope over time, but when you first kicked it off, it was you were using GitHub issues, you thought they were lacking this project management visual Kanban thing. And you decided to build it. Were you just scratching your own inch back in the day? I guess it was really born out of a need or maybe even like a hatred of other tools that

I've used in the past. You want to name any names? I don't think the great hatred tool needs to be mentioned more like the Vault more. Yes, the tool that will not be named. Everybody's used the tool that will not be named. And although I'll just come out and say like it's usually jira right and um i i think it's it's a fantastic tool for businesses it's so it's so uh configurable almost to a fault right like yes you you can you can put so many rules uh dictating the the flow of your issues with that tool that sometimes it gets cumbersome to use. What really made Hooboard come about was a little over three years ago, I came to Austin to work for a company.

And we were building a really complex, as far as business rules and requirements, enterprise application for large enterprise HR needs. And so there was a lot of rules around who could see what data and things of that nature. We really had this fine-grained requirement to lock down security down to like the field level of like like sally sue can't see the salary of x person right if they're not in this certain role and so to fit that bill we actually ended up building a web framework and we decided to open source it to try to like kind of get a groundswell or like a force multiplier of

productivity and so we of course hosted that on github and that framework was called fubu mvc so sort of as open source developers on github you know we were in github love github we ended up choosing it for the business side of things as well. And so rather than using multiple tools, we kind of settled upon GitHub issues for the product side of things. And what we kind of found was the simplicity of it is fantastic for an open source project, but it has some shortcomings as far as communicating to a business and prioritizing a business's needs versus an open source project. Okay. GitHub Issues is fantastic, but it doesn't really have any prioritization or any sense of where things are, whether they're in progress or in review. I don't know if you guys have ever personally tried to use GitHub issues to manage a project.

We've gone off and on using that between – we use Trello now, but we mainly don't use GitHub issues because we use Trello now, but we mainly don't use GitHub Issues because we use Trello. We have business sides of the house that need to sort of play a part in moving cards around and seeing the state of things and commenting and coordinating and stuff. So Trello is fit for us, but we did try GitHub Issues way back in the day, and it was label hell. It was the same thing you're talking about. You couldn't really tell where something was at in the process. And that's what we liked about Trello, which was this sort of Kanban approach to how you can do things. Right.

And Trello is fantastic too, right? It's extremely simple. non-technical stakeholders, it's a lot easier to say, oh, hey, here's this tool, and it really only is around issue management or project planning, rather than trying to get a non-stakeholder to be like, oh, hey, you have, okay, so we use this thing called GitHub, and you have to explain what GitHub is. And then you have to, they have to go create an account in it. And they're like, well, why do I need this account just to manage issues and yeah very confusing so there's definitely we have that with documentation too because we have wikis and some documentation in our repos and it's just like unless you're a developer on the

development team you don't see that stuff and it's or they do they just forget they have a github account they don't know how to log in. It's just like, it's totally foreign to them. Right. And so, you know, back to being at this company, we ran into all these problems, right? Because we didn't want to like use different tools. And at this point we have, you know, hundreds of open issues, you know, a lot of them like two to three years old in GitHub. And, you know, we started like making duplicates of old issues. So it just became like a bit of a nightmare to manage.

And so we started playing around with the API and trying to find solutions as to like how maybe we could better organize them, right? And so we came up with this tool called, at the time, I think we called it Hookshot. And so what we did is we subscribed to the issue webhook, right? And so anytime an issue was closed, if it didn't have this reviewed label, we would basically reopen it

and add a needs review label to it and assign it to our QA engineer. And so for a while, that really worked. So we would basically create an issue in GitHub, and then we would use the linking part. It's a feature in GitHub where if you reference an issue number in a commit message, it will actually link that SHA and that commit in the discussion history of a GitHub issue. With a timestamp and stuff. With a timestamp and you could click on it and go and you can actually make inline comments on a certain line of the commit.

And those actually come through into the GitHub issue discussion. And they actually have some really fantastic features around really integrating it in with your code. And so that really helped our testing and QA engineers see. They could go to the – so they would get tagged with needs review, right? And they would get it assigned to them, and they'd look at it and be like – and they would be able to easily reference back into the code what actually changed. And so we really fell in love with that functionality. When we hit some of these shortcomings of GitHub as far as communicating the business, what we were doing, right? Because we're programming, right? We're busting out features.

We're being productive. But some of the stakeholders didn't really see that. They didn't really understand how to extract that value out of GitHub, right? Because they didn't really see it. Like, you can't see the progress. And so we didn't want to lose that code linking, but we saw this need for, like, visibility to the business. So we started looking at tools like Trello, like Pivotal Tracker, like Jira. And I came up with a crazy idea.

I was like, well, what if we had this conventional label, right? Almost like a Kanban board. We could just name a label with a certain pattern, and then I could use the API to pull all those labels and then turn those into columns. And if you drug one issue from another one, I just remove that label and add the other one, right? And so I just spent a weekend or two hacking on it,

and that was what birthed the first version of what eventually became Hooboard. And at that time, I called it Inch Pebbles. Inch Pebbles? Yes, it was a playoff of Milestones. Okay. Milestone, inch pebble. Got it.

So clever. Yeah, very clever. And so Inch Pebbles was born. It was hosted on a free dino on Heroku. I'm a.NET developer. I don't know any Ruby. So I write it in ruby because you know heroku was like free and i kind of wanted to learn ruby so it was just kind of like this

yeah it's 2011 so it's just like the side project it's running on a free dino it really only like had you couldn't create issues or anything. It was effectively, like, you could navigate to this page that had the same URL structure as GitHub, and you would see this Kanban board just magically appear. As long as you had these specially named labels, and we could drag them, like, basically say, hey, here, business, here's this Kanban board that can just show you this like read view of what we're doing. So it sounds like you could still use issues as normal with a dev team, but hand them Hue board, the business team Hue board, and just especially name some labels. Is that what you're talking about at this point? Where you still had issues and it's still worth the way issues works, but you can use this in tandem. Right. It was really – it's really just a different view on top of GitHub issues.

Like there's no separate data model. Like it would pull the issues from the API and create cards from each issue. And it would look at the labels on the issue. And if it had one of these conventional labels on it, it would then be in that column. It would just be represented in that column, right? And it just had a really simple, like, if like a, like jQuery draggable, like, oh, if you drag it over here, then it just made an API call that removed X label and added the other one, right? That represented the new column. And so it just was born out of pure need and pure simplicity, right? I started showing people that I knew.

I'd be like, oh yeah, I made this cool thing. Check this out. And like, I would just show it to people. And they're like, yeah, that's cool. Like we would kind of be interested in using that. So I was convinced to like show the world like reveal it like let let people use it so i go shopping for the domain name inch pebbles and it's taken what it's like yeah it's like parked by this blog man so i did i just didn't want to i didn't want to go through the hassle of trying to get that name from whoever you know randomly had somebody else thought of inch pebbles that's what i'm impressed i guess i don't know and uh the tagline of this this blog is like uh dealings dealing with life's milestones or something like that i mean like it even had the

same word exact play it was so great uh so then we started brainstorming on names, and things were thrown around like Octocards, Octoboard, kind of playing off the Octocat thing. But then that didn't really have anything to do with a board or I don't know. So somebody just threw out, what about Huboard? The play on words from Hubot. Yeah. And so it had some, like, it kind of had, like, a backwards tie back to GitHub. But it really kind of gave me the freedom to sort of be unique in a way or claim that I wasn't. So, like, if you ever wanted to like use it or like build an

adapter for a different issue tracker maybe you know the the word would or the name would still be relevant yeah so yeah hubord was born and jared and i were saying we thought it was hub hub board hub aboard i don't know how too many i don't know it was there's not two b's i don't know. There's not two B's. I don't know. I was lost. You probably know this, right? As developers, we spend most of our time reading words on the internet.

And we don't ever have to say those words out loud to anybody. And so we all come up with our own rendering of what that actually sounds like. And then we get together with other developers and we finally use that word and they give us this stare like, man, what are you talking about? And you just realize that my version of that word

is just completely, does not line up with reality. It's like OzCon or OSCon. Yeah. Or Imgur. I don't even know what that is. See? Yeah, you never go on Imgur? Yeah, exactly. M-I-G- go on Imgur? Yeah, exactly.

M-I-G-U-R dot com? Yeah, exactly like that. No, it's Imgur. Definitely Imgur. Imgur. So you mentioned switching out the possibility, because the name is a little bit distinct, that you could have a separate back end,

which makes me think of one concern that I had, you know, hearing about it is like, you know, because you're building a business, you've built a business around Huboard and you've, we'll talk about, you know, kind of some of the challenges and things that happened around this business around an open source product. But were you scared to, obviously not scared enough, but did it bother you or that you were building a product on top of somebody else's product? At first, I guess I didn't have – when I set out to build it, I didn't particularly have the intention of turning it into a business. So my concerns around not having the stickiness of the tool, I like to call it stickiness, right? Like, I don't own the data model.

It literally, all that controls Huboard is still in GitHub, right? Huboard is not the single source of truth at all for what represents the state of the board. So there's really not much stickiness in the tool like it's really easy to use it try it out uh even use it for a while and then maybe you outgrow it and you could go to something else there's nothing keeping you using the tool right that's a blessing and a curse though because you also have it's really easy to try it out too right so there's your blessing and a curse, though, because you also have, it's really easy to try it out, too. Right. So there's your blessing. The curse is it's also really easy to just ditch it.

Just to ditch it. So being that I didn't set out with the intention of turning it into a business, I of like it was fun to try to see how far you could stretch using an API and not have a database whatsoever, right? Like Hooboard existed and I kept adding features like linking repos together, custom ordering of like keeping the order of where cards were,

flipping the board on its side on milestones where the columns were milestones, being able to order milestones as a custom order instead of the due date. All these things I was able to do for free. I didn't have a database. It cost me nothing to host it. It pretty much lived on a free Heroku dino for like over two

years. I think, I think at its peak when, when I wasn't charging any money, it was somewhere around like, and again, like I didn't have intention to make it a business. So I didn't even really have any metrics on like how many users there were. Right. The only metric I had to go by was, like GitHub has this thing when you create an application, they'll show you how many keys your OAuth application has authorized. And so at the time, it was like somewhere around 6,000 or something, right?

I don't know how, you know, I've never spent a dollar on marketing or anything, but somehow it just groundswelled into all this interest in people using it. And it didn't cost me anything to host. So I was like, okay, la-di-da, you know, like I just kept trying to, trying to stretch it, trying to stretch it, see how far I could take it without having a database. And then when the, when the time came to where like it kind of got so big that that other companies saw it as like an opportunity to make money i had a decision to make right it was like let let my experiment die like let the thing i build built die to people who were like turning

it into a business or turn it into a business myself right all right let's pause the show for a minute give a shout out to a sponsor. I want to talk to you about TopTile. We've been working with them for the last year and it's just been a great time working with them. We thought it would make some sense to circle back and talk to some of our listeners who've applied with TopTile and have been accepted

because only about two to 3% of the engineers who apply make it past their strict elite engineer process and that person is daniel alzahn a longtime fan and listener of the changelog he is now living the dream as an elite engineer at toptow and i say living the dream because he's now able to have 100% control of the types of projects and technologies he's working on as well as the rate he wants to charge daniel earns 100 of his income as a TopTile engineer, and he wanted me to pass on his seal of approval, so to speak, of the TopTile experience. And for those of you out there who are freelancing or would like to test out freelancing

or even try out a no-risk freelance-like project while you maintain your full-time position, you've got to check out TopTile. If you think you have what it takes, head to TopTile.com to get started. Tell them the changelog sent you. And now back to the show. And you had some real competition come in and offer

a very similar product. Is that fair to say? There's a couple of competitors that have come into the space and some of them are like really really similar as far as like almost clones and then there's others yeah right i don't think anyone's forked the repo per se but um they definitely were largely inspired by by keyboard right and that's not bad. Like competition is good. Right.

It, it convinced me that, that it was a viable thing. Right. It, it inspired me to like, take it seriously and take it to the next level and like, like build in things like SSL support and, and stuff like that. At the same time, like if I could do it all over again, it sure would be nice to have some, some inkling of stickiness to the tool, right? But at the same time, it's okay. It still gets a lot of interest and a lot of people use it and like it. I guess it's a challenge to keep the tool compelling and good enough that people stick around even though there's really no reason to. Yeah, I think that's a testimonial for the tool.

It's awesome you got there with no marketing too, to have that many OAuth keys in use. I'm looking at our notes and I've got a note here that April 19, 2012 was when you said somehow on Twitter, somehow Hubor grows to 400 users. Is that the 6,000? Is that post that or before that? I don't remember.

I was preparing for the show. I was trying to go back in my Twitter history and figure out how big it was at certain points. And that was just a random tweet that I came across. my Twitter history and like figure out like how big it was at certain points. Right. And that was just a random tweet that I came across. Right. So who board.com really kind of launched, like I wouldn't say it like actually launched. Right.

Like I, I told people about it on my personal blog in January of 2012. And by April, four months later, there was already 400 people like using it by the time like i got to the 6000 mark was when i really took it to like actually formed a business out of it and launched it uh launched it out of free for everyone you know over a year later somewhere in like october of 2013 is when we so when we so when i actually like

keyboarding came into play right so when so when i formed like an llc to actually charge money to people it was over a year you know later yeah and and it had still it had grown up to like that many like user keys that had been authorized that's not that's probably not like a fair metric as to how many people were actually using it right like because some people would maybe like check it out and then you know you tick the number but uh it was pretty it was still pretty impressive for me like you know you just keep getting into those like-based milestones. Like, woo, 1,000, woo, 400. Every 100 I would kind of be pumped up. So you had all these free users

and there was all this interest and buzz despite no marketing. Then competitors come in and they start to offer your product or a very similar product to yours for pay. And so you decide at this point, I'm not going to resign. I'm going to man up and turn it into a company. And you relaunch as a business, paid accounts. Did the people just fork over their money immediately? Or was there still a moment in there where after

you turned it into a company and decided you're going to start accepting money where you had all the free users, but nobody was interested in paying, or did they just sign up right away? Yeah, so that was an interesting thing. It was foreign territory to me. When you take a thing from free to for pay out of the blue, a lot of people go the route of grandfathering in, you know, the people that are already using it. I didn't do that maybe out of laziness or maybe out of like urgency to put it out there. So when I launched it, I launched it with anyone who signed up within the first year got a six-month trial.

I basically kind of – I saw that as a way like, hey, I'm sorry. Like I kind of got, I got to turn this into like something real. I understand you're using it for free. If you sign up, like I'm not charging anyone. You know, if you sign up before November 1st, you get 180 days free trial, right? Which is like a really long time. And there was maybe a thousand, after you do some analytics and slicing and dicing of who's using it,

there was maybe a thousand potential paying customers at that point. And I was just kind of okay with the fact that I wasn't going to convert all of them. And that's in fact what happened. It ended up being that I didn't, I didn't convert everyone. I lost a large majority of those people. It's sort of, sort of like starting from scratch. And, but like, I guess any SAS business, it's kind of like that. It's,

it's a slow linear growth until you hit that thing that makes you like do that exponential bell curve and then everybody uses it. It's been a little over a year now. And we've hit being fully bootstrapped with zero outside funding. We've been able to – I have hired my first full-time employee, which is absolutely nuts, about a year later. All, you know, just kind of bootstrapping it,

staying profitable, staying soluble the entire time. Well, congrats on that for sure. Yeah. You know, for those who don't know, this is completely open source. So if you wanted to check out HueBoard, you could just go to github.com slash ryan slash hueboard, which is always admirable and interesting

when we see people building open source products and then also turning those into businesses that are successful. I think the stigma is that that won't work because people will just clone it or run it themselves. Your audience is developers in a large part. I guess we can talk about your growing customer base and how it's turning more enterprise next. But first I want to ask you about the open sourcing of it.

I'm sure it was probably open source from the beginning. Is that fair to say? It's been open source from day one or did you open source it at a certain point? It was just open source from day one, or did you open source it at a certain point? It was just open source from day one. I just threw it out there. Like, hey, here's this random cool thing that I built for fun. I open sourced it from day one. I made it MIT just out of, I guess, randomness.

Like, oh, I'll just pick that one. That one sounds good. You also have a contributor license agreement too. How does that differ from the MIT? So I actually added that later. I added that after I turned it into a business. And that was more because when it turned into a business, it's just out of ignorance.

I had no idea like, well, what if somebody does fork it? It is MIT. So someone could host it and make zero changes and charge money for it. That is completely within legal realm and you can do it and that's fine. MIT does not stop you from doing that. So when I launched it, I was contemplating changing the license to AGPL, which would kind of prevent people from doing that in a way, hosting it and then gaining money from it.

But I actually never did that. I just left it. At the end of the day, no one did it. No one forked it and just tried to make money on it. And I'm not the only... Hooboard is not the only company out there that has figured out kind of a way to charge money or at least sort of make a living off of their open source

contributions i mean docker's doing it vagrants doing it you know discourse is doing it mike perman i'm probably gonna butcher his name yeah we had mike on uh last summer talking about his business around side yeah he's he's been able to do a really similar thing to Huboard as Huboard, right? And like productize, he kind of has this open source version and then this pro version, right? And that's kind of the same thing as Huboard, right? Like you can certainly host Huboard yourself, right?

But I think that we're within the realm of reasonable pricing that even if you do it on Heroku, all of the components that run a production instance equal or less than just paying for Hubor.com, right? Which also makes it keep getting developed and hiring employees and supporting the software, upgrading the software, current version of Rails, you name it, right? Right. One of the things is when I launched it in October, it was – you couldn't even create issues. You had to go to GitHub to create issues. It was literally like – It was like organizing. Right organizing right read only or not read only but not it wasn't read only but it was like it was like maybe i have this perfectionism

in me right that i was like well i don't want to provide a ux that's not as good as github right and i saw like creating issues as like, well, you know, there's a lot of ways to create issues. And that's a lot of effort for me to do that. You know, for the most part, I didn't see it as like that big a deal that you had to go to issues, go over to GitHub to create your issues, right?

But feature parity became like my highest priority when I started charging money for it. When you're not charging money for something, you kind of have this leeway to be like, yeah, I don't have that. But when people are paying money for it, they don't really take that as an excuse. So charging money for it funded improving of the tools. And that actually goes back into the open source version. So I wouldn't have done those things if I wasn't charging money for it. I'd probably still be like, nah, just go to GitHub for that.

Or use a command line tool. So coming up to feature parity was a big thing that was funded by getting money increasing the performance is something that is funded by that and enterprise support as well so things get better if you pay for them everything can't be free I guess so there's this old story about Apple and Dropbox

back when Steve Jobs wanted to acquire Dropbox, and he kind of took the strategy of making them feel like they needed to be acquired because he told them, all you are is a feature. You're not a business, you're a feature. And that was not a winning strategy for him at the time, and we've all seen what has happened with Dropbox, grown to be a massive company since then. I think perhaps a naysayer, a few board would say,

are you not just a feature of something that GitHub could add and then you'd be out of business? Have you thought about that? You know, it looms in the back of my mind, right? But then I just, I wonder, you know, part's looms in the back of my mind, right? But then I just wonder, part of me thinks whether or not that's really what their focus is, right? Their focus right now is how do we make collaborating and sharing code more important? You see it in their entire tool chain is that GitHub is about sharing your code. You can even see it in their permissions models.

When you give somebody OAuth access to your repo, you get everything. There's no way to just say, oh, give me issues only. I think it flies in the face of their entire business model. They exist to share code. So why would they cripple their own tool and not give you access to code, if that makes sense? Yeah.

You know? Well, I would think of it as a feature ad on top of issues. Like you said, keyboard was a view. It's a different view into issues. Obviously, it's grown. So that was kind of the initial feature the initial conceit and they've also done some redesign to issues too like it's what's gotten you know full width and there's been enhancements over the years of issues too so they've definitely been paying attention to right the usefulness of issues and and according you know and according to their blog posts they spent nine months on their their redo their latest redo of of issues and you know nine months of work and it it didn't

really significantly change um they still i think to the core they don't think you need anything more than what is there. And in some aspects, I agree. The original vision and my vision for Huboard is not to particularly change the way you should use GitHub. It's kind of to enhance the way that you use GitHub, right? Like, I believe wholeheartedly in GitHub flow. My own personal development flow is, right? Like I have master and master is always deployable. And when I want to work on something, I cut a branch. And then while I'm in that branch, depending on what I'm working on, every commit is tied to an issue number, right? So that I have like this full traceability into whatever it is or was.

And then at the end of that, that turns into a pull request. That feature branch turns into a pull request and somebody other than me looks at it and merges it in, right? And that's how like my entire team, the two of us, that's how we work, right? Like we don't require like a daily stand-up meeting or anything like that.

Like we collaborate through like – The tool itself. The tool itself, like GitHub itself. And really, Hooboard is an effort to like enhance that or make that easier or like visualize that workflow, not like change it. You know what I mean? Let's ask a different question then. What if, um, let's say there's a GitHub or listen to this.

Let's say it's Chris Wallenstroth for what, for whatever reason, he's listening to the change log. Hi Chris, by the way. Um, and he's like, you know what? I like what you did here, Ryan. And he, he, he wants to acquire you. Is that an option for you? I guess, I don't, I don't know. I would, I would take an unsolicited offer, uh, any day guess i don't i don't know i would i would take an unsolicited offer uh any day i don't know necessarily do you want to become a githubber it depends they're just tumbling over there everything's for sale at the right time but like is that an out strategy that

i've i've thought of? Of course, right? Maybe. It depends. Like anything, it depends. It comes back to that question, too, that Jerry was asking earlier, which is – well, I think even you mentioned it, Ryan, which is that you could write an adapter for a different application other than GitHub issues and still take Hue board and do something with it that's useful. I think what we're trying to get at here is how much anxiety looms over you over the fact that you're building a business on top of a business and that even the data model you don't have control over and any of the day you're not the canonical data source even. Yeah, and I do. I wouldn't say it keeps me up at night, but yeah, I think about it. I definitely think about it. Not being the single source of truth, as far as the viability of a business, personally, I'm a developer. I have a skill. I built this thing. Like, even if it fails, at the end of the day, I'm not going to be unemployable. But yeah, once you turn into a business and you have employees, your concerns change, right? Like, I'm more concerned about the well-being of the person

that I convinced to come work for me than I am for my own well-being so yeah that really concerns me yeah at the same time i just don't i don't think github is in is secretly working on a kanban view for for issues probably not yeah i don't think so i would worry about it i just wondered if you were worried about it right i would think that they're ethical enough to let me know or or at least oh maybe business savvy enough to be like to at least exhaust acquisition avenues before before before committing their own development time right yeah let's pause the show for a minute give a shout out to a sponsor digital ocean simple cloud hosting built for developers in 55 seconds you'll have a cloud server with full root access, and it just doesn't get any easier than that. Pricing plans start at only $5 a month for half a gig of RAM, 20 gigs of SSD drive space, one CPU, and one terabyte of transfer.

That's a lot for $ bucks a month. DigitalOcean also has data centers all across the world, New York, San Francisco, Amsterdam, Singapore, and their newest region, London. You can easily migrate your data between those regions, making your data always closest to your users. Use the promo code changelognovember in lowercase. It's important that you use lowercase. changelognovember to get a $10 hosting credit when you sign up.

Head to digitalocean.com right now to get started and back to the show. You said that GitHub acquisition would be a decent exit strategy for you, but the fact of the matter is that you don't need an exit strategy at the moment. You have a growing business, a very small, probably, overhead. And you have some increasingly large customers. Perhaps a surprise to you is how many enterprise customers you have on your homepage. I see Microsoft, Mozilla, Adobe amongst your customer list. Tell us about the enterprise and your success there and challenges.

So on the enterprise site, those are actually SaaS. Oh, are they? They're not? Yeah. The dirty little secret is that when you get into enterprise, I really am contractually restricted

from telling you who actually bought it. If that makes sense. So by enterprise, you're speaking of a different product. This is an on-premise product as opposed to just like a large enterprise company that's using your SaaS product. Yeah. Over the lifespan of Hooboard, there's been a lot of interest in providing GitHub enterprise support, right? GitHub Enterprise support. So a lot of people may not be aware of it,

but GitHub offers an on-premise version of GitHub. You can go to them and they will give you a virtual machine that has GitHub installed on it. And you can basically, as simple as importing it into your vSphere or your Essex environment, you spin up this VM, you upload this package, they call it the thing's fully provisioned and it is literally like GitHub inside your network behind your firewall, which is really incredible way to like deliver software. It's really fascinating. And there was like tons of interest for people that were like, hey, we want to use Hooboard for our internal GitHub Enterprise instance. And it seemed plausible. You weren't sure.

Well, you know, it was like, well, they claim that their API is fully compatible. It should work the same. So it should be as easy as, well, we'll just point it at GitHub Enterprise and it should work the same so you know it should be as easy as you know we'll just point it at github enterprise and it should work right it turns out that big companies are are not particularly interested in they weren't or aren't like interested in taking the open source version of hue board and sort of hosting it themselves and pointing it at their GitHub enterprise, right? Like there's some challenges around configuring it correctly and updating it. And like, you're going to have to pay a full-time engineer, right? Or, or somebody

to maintain the thing, to know how to like, if I made changes to the, to the database, it uses CouchDB. That's not a widely used or commonly known thing. How do you migrate documents in CouchDB? That's kind of a thing that isn't going to be easy for me to put in a wiki, and I'm not particularly going to want to sit down with somebody who isn't paying me money and walk them through how to do it, right? I'm likely going to be like, no, that's okay. I'm not interested. That being said, there's a ton of interest in enterprise support.

And maybe me being a perfectionist, I really wanted to give the same experience as GitHub Enterprise itself, right? So we set out to build a virtual appliance that, you know, kind of like reverse engineered GitHub Enterprise itself and tried to build the exact same experience. Did you collaborate with them at all on that? Did you like work with the github enterprise team by any chance so no and yes at the time it was like for a long time it was this it was this growing interest in it and i was like well does anybody want to like loan me their github enterprise environment so i can test this thing you know at the time i didn't have any money. I'm not going to go pay $5,000 for a license to GitHub Enterprise just to test something that I don't

even know anyone would pay for. I asked GitHub for a license to GitHub Enterprise. They were like, here's a 90-day free trial. Then 90 days later, I still didn't have a product. And so I think part of that effort kind of got them in gear to start their developer program. And so now you just enroll in their developer program

and you get a license to, to get up enterprise now, which is really nice for, for integrators like myself. But as far as like building the, the virtual appliance itself, like there wasn't a whole lot of back and forth with the enterprise github i i did ask them you know we we asked them some questions around like you know how are you how are you exporting you know how are you creating this ova that that like cleanly installs into vmware and stuff and they actually like were really helpful and uh someone from their team like provided us with like this code that like I think that was our one hanging point. We couldn't get it to cleanly import into VMware without it complaining about its

manifest file being corrupted. They definitely helped with that. They helped. They helped. That was a really long explanation. It's just interesting because that's the help. It's just interesting because, I mean, that's one of their obvious directions in their business, and you just wonder how flexible they are to – and even them helping you with that enterprise integration might give you some signs of bright spots whether or not they're going to consume you at some point.

You know what I mean? Well said. Yeah. Consume you, take you over, eat you, whatever. Stomp on you or acquire you, whatever you want to say. It sounds like you had some technical challenges around creating this virtual appliance. Any interesting stories or neat solutions that came out of that, uh, technology wise, um, or maybe even the toolkits that you're using to build these, this, uh, virtual appliance.

You know, the interesting thing is there isn't, there isn't a lot of tools out there, uh, for this, um, no stack overflow, not really, you know, there's no guide or screencast on like, or blog about like how to create a virtual appliance. Like, how do you create this virtual, you know, how do you create this VM that gets deployed on someone else's network? That, you know, if you sell this thing to a Fortune 500 company, you're going to see big boy networks, I like to call. These things are like lockdown.

If you want to reach out to the internet or outside of their firewall, you need credentials to get out of their proxy servers. So things that you take for granted, like gem install or bundle install, try to do that without the internet. Things like apt-get install without the internet. Handling things like self-signed SSL certificates. Man, I can't do anything without the internet.

I try to get on an airplane thing. I want to get a whole bunch of coding done. It's going to be awesome. And then I realize I didn't prepare some sort of docs I need, and I'm just like, screw it. I'm going to watch a movie or something. Right. And then supporting something that you can't touch or see.

Yeah, how do you do that? Poorly. Poorly? Yeah, how do you do that? Or C, poorly. It's a lot of back and forth. Sometimes it's screen sharing. One of the biggest challenges usually is around SSL. People will configure, customers, sorry, will configure GitHub Enterprise with a self-signed SSL certificate, or they'll use like a certificate chain that isn't installed by default in Linux.

And so getting those onto the machine is probably the biggest hurdle. And then, you know, you run into challenges of like, you know, you have to configure the network to speak to internal name servers. Because like how do you resolve github.company.com when it isn't in a public name server? It's in an internal name server, right? So you're given this string of this host name, but you have to talk to an internal DNS server to get the IP of the machine.

Yeah, it was challenging, right? And coming from a guy who started his career as a.NET developer and then did this out of a whim, wasn't even a Ruby developer, and having to debug some of these things like open SSL peer verification. Going from a front-end heavy developer to a full-fledged DevOps engineer is something I never expected my career to take a path to. So is it worth it?

It's worth it. So I've had a couple people who they're also building GitHub-focused products that extend GitHub. I've had them approach me and ask me questions know, ask me questions like, how did you start this? What's your relationship with like, with GitHub? And I've also reached out to other ones like Travis CI. I've had conversations with Matthias, I think his name is, you know, and asked him questions about like, how how they do stuff. And it comes up like,

do you regret doing enterprise support? And at the end of the day, no, of course not. It's very lucrative. But you're talking about, in some instances, it's a 10-month sales cycle. So unless you have that SaaS backing to sustain you through that 10-month sales cycle. So unless you have that SaaS backing to sustain you through that 10-month sales cycle, it's not going to be fun, right?

It's a lot of work. There's a lot of red tape you have to go through to sell to large enterprises. But it's a learning experience, I'll tell you. If you guys ever really want to know the contract negotiations and stuff like that. It can be.

Well, since we're talking about pains in the butts, maybe it's a good segue to something that's probably a deeper topic, which we may not have the full amount of time we should actually give this. So I don't know if it's something we can talk about in the sub-10 minutes we have for this show left or not. But can you talk briefly about the technical stack that you built upon? I know you started in 2011 from a Java background. Dot net. Used Ruby. Sorry, was it dot net?

It was dot net. Okay. I remember talking earlier to you about somebody doing a Java project. I thought Java for a second. Doing Ruby, mainly to use Heroku for free or OneDyno. Can you talk about your tech stack and just what you're using to any degree?

Yeah, sure. The WhoBoard API itself is effectively a Sinatra app. I've rewrote it probably four times, and they're improving it and stuff. And I settled on, and I'll give a little shout-out to, I forget his name, Andrew Macarey? That's what I call him. He wrote a tool called Monocle and I think he has a new app called... He's a big Sinatra guy. He wrote a tool

called Trevi, which is a little... Some patterns he uses to build Sinatra apps. I eventually refactored to that and it's good. I think eventually we will rewrite the majority of it in Rails. I like to say that there's a lot of paper cuts with Sinatra,

and once you get to a certain size, it's just a lot easier just to go with Rails. Rails is pretty fantastic in that regard. The front end, I rewrote in Ember.js and love it. It's great. I highly recommend Ember. It's such a – When did you rewrite? Oh, last year.

January-ish of last year is when I released the full Ember rewrite. Previously, it was Backbone. And three years ago, Backbone wasn't even 1.0. I think I started the project with Backbone 0.3.3. So it was definitely bleeding edge from the start. And even with Ember, it was still pre-1.0. We store some things in CouchDB. We, of course, use Redis as part of our stack, Memcached. We do some real-time communication stuff with WebSockets.

That was kind of a journey. I started out with Socket.io. That worked great for two and a half years. Literally, it was like 40 lines of JavaScript that I never touched for a two and a half years. Literally, it was like 40 lines of JavaScript that I never touched for a year and a half. And then I had some problems with that and moved to a hand-rolled Sinatra streaming server. And then I had some problems with that

and then eventually settled on Fae. I've used Fae in the past. Nice tool. It's not perfect. I really wish that I could use something like Pusher or PubNub. Why can't you? Enterprise. To be short and sweet, Enterprise. I have to be really cautious in particular about the technology choices that we make

is because everything still needs to run on a VM for enterprise. Some of these really fantastic services are kind of out of reach unless they're easily hosted. We're doing some things around

right now. We're doing some things around right now we're doing some things around improving performance uh making speeding things up and building some business insights and some analytics into uh like you know lead times of cards things of that nature uh we've settled on the elk stack log stash uh elastic search cabana puppet of course is the magic that The Elk Stack, Logstash, Elasticsearch, Kibana. Puppet, of course, is the magic that Hooboard Enterprise is built upon. And then shout out to Heroku. They've been fantastic. We're still on them to this day.

I think Hooboard chugs along. I think we have 6,000 average monthly active users really pounding it. And we're on two extra large dynos. Nice. Not extra large, but the 2x dynos. So that's pretty great. We have some things on AWS, of course. I guess that's pretty much the whole rundown of our stack.

Awesome, man. Well, unfortunately, we're running out of time. Otherwise, we would question you on individual choices, why Ember, why Couch? We love those kind of questions. I have more questions. We just can't answer them. We can't ask them.

Can we maybe ask this one question before we ask the final question? What you got? I don't know if you've – and maybe this is a short one too, which is the fact that you're open source and accepting contributions and pull requests. I know we talked about the license there, but did we just kind of close the loop on how you deal with forks and pull requests back to the open source version and how that plays into just this fact? Because it brought that up in my mind whenever you mentioned enterprise and how every time you make a choice on what to use and code to add is based on whether or not enterprise gets supported. We don't get a whole lot of pull requests. Bad on me, there's one in particular that's been open for a while, which is add milestone.

It's been open for a couple months. Unfortunately for him, it was in the middle of a big rewrite that I made. And so some of his stuff didn't merge in cleanly. Accepting contributions is hard. It's difficult ethically and it's difficult legally too. I don't really know the specifics, but I guess to try to cover all my bases, I do ask people to sign a contributor license agreement, which basically just says, kind of do whatever

we want to do with your code. That being said, anything that's within the MIT license. Just ethically and for me, if somebody contributes something significant to the open source version, I will do my best to

continue to support it forever. I'm not going to take large contributions lightly. If someone contributes something that's significant, I'm going to make sure that I can support it because you can't really trust somebody else to be there forever, right? So if I do, I will make sure that it's

going to be supported forever. Other than that, there's people that have forked it. CrushPath is a big one. I think they're a San Francisco startup. I know that they run a fork and they've added tons of features that are important to them. And then for a spell, Shopify had a fork that they were working on, but that kind of disappeared. I'm not sure if they privatized that or what went on there if they decided to do something else and deleted it. But there are people that exist that have forked it and added features that they care about, but they necessarily haven't contributed back, if that makes sense. All right, Ryan.

Well, it's time for those closing questions. As a ChangeLog listener, you probably saw this one coming, our old favorite. Who is your programming hero? This kind of changes on a frequent basis. I always look up to a good friend of mine, Charles Lowell, Cowboy D on Twitter. But lately my programming hero has really been my girlfriend, who is a budding female learning developer. About six months ago she

left her cushy support job and leap did a leap of faith and she's learning to be a developer so nice you know that that really it's fun to see her learn and grow and to do it at a kind of a later age as well you know when you already have an established career and the risk you know yeah Yeah, it's a big deal. I'm kind of in awe and a bit of a hero to me. Gotta give a shout out there. Awesome, man. Make sure she listens to this so you get them brownie points too.

Don't miss out on them brownie points. Next up, and a new question. Trying to share the podcast love a little bit and give some shout outs to different podcasts out around the ecosystem. So you're a podcast listener, please, if you would share us,

share with us a couple of your favorite podcasts. I'm a big fan of the JRE, the Joe Rogan experience. If you guys haven't heard of it, Joe Rogan, yes, the one and only fear factor host from way back in the day. He has one of the most popular podcasts in the world.

Strap in. It's three hours apiece. I don't know. I enjoy it. I think we should do the changeling for three hours. That's a long experience right there. That's a long experience. What else?

Any other shows you got on your podcast app to you guys of course i'll listen to the the front side podcast um like front end development or design or what's that the front side it's it's charles's little just personal thing cool i've listened to ruby rogues and javascript Jabber. Sometimes I still tune in to Herding Code, which is a.NET-focused one. I'll listen to the Ruby 5x5. You mean Ruby 5? Ruby 5.

The Ruby 5? You mix Ruby 5x5. Is that a new one? No. Ruby 5. You also have a Ruby on Rails podcast on 5x5. That's right. You can probably add that one to your list too.

I like that show. You know, we obviously love podcasts. We appreciate you listening to our show. That's totally cool. And I guess to wrap up the show, it's been great talking to you. I know we saw you back at Keep Review Weird in Austin. What was that? October, Jared?

We were there? Somewhere. Yeah, October. September? October. That was good times. That was good times. We do have some pending video we shot there, and you'll get to see Ryan's awesome face on the video.

Sharing, once again, his other programming heroes. You didn't mention your girlfriend in that one, but maybe she wasn't your hero then. Keeping it fresh. Keeping it fresh. Yeah, Ryan, it's been great having you on the show. I know we're definitely excited about where you're going with this. It's fun to see.

We've seen this time and time again. You mentioned Mike Parham and others, Tim Caswell. The list goes on of people that have been on the show that have done something in open source and found a way to make it free and open source but still make a business out of it and support it. We think that's always a great one, and we want to highlight that one when we get a chance to do so. Yeah, I really appreciate you guys letting me on. One thing I want to say too as a close to this uh it's a two-part thing one to promote our issues or sorry our ping issues on github and two just to kind of maybe get a shout

out from listeners of the show that use hue board if you are a user of hue board or if you love this show go on to our github issues it's uh github.com of course slash the changelog slash ping and submit a new issue um if there isn't one yet and if there already is one just go and throw a comment on there and give a shout out back to ryan about just using hue board and what you thought of this show or whatever that'd be super cool to just kind of see who listens to this show and see who's using hue board and try to connect the dots a bit but uh we do have some pretty awesome sponsors that helped make this show uh possible we got code ship definitely love code ship who doesn't want to have tested code in production right that's that's that's the name

of the game right rack space and top towel keeping us on the airwaves yes rack space code ship and top towel friends of the show they They support us. They love us. And we hope that you love them too. But that's it for this week of The Change. We'll be back next week. But for now, let's say goodbye. Goodbye. Bye.

Bye. I'm out.