Learn more about GitCommits at: https://www.gitcommits.com/
Find Drew Angell on LinkedIn here: https://www.linkedin.com/in/akangell/
JC: Welcome everybody to another episode of The Future of BizTech. I’m your host JC granger, and I have with me here, Drew, who is the founder and CEO of GitCommits. Drew Angell, please tell everyone about yourself and a little bit of your background.
Drew: Sure. Yeah. I’ve been doing web development for quite some time, primarily specializing in payments and a lot of PayPal stuff. That’s kind of for the past 20 years or so. I’ve had my business Angell Eye where we’ve been doing a lot of web development and things like that, kind of turned into a partnership with PayPal. And out of that has branched GitCommits, which is a new platform that we’re launching that we’re pretty excited about that should help kind of grow all sorts of development stuff within us here.
JC: Tell us a little bit about that. Tell us about GitCommits and then segue also into what is the biggest pain point or problem that GitCommits solves for companies?
Drew: Okay. Sure. To try to keep it short as possible here, it’s basically a way to take the Git community, so GitHub and Bitbucket primarily are the most popular ones, but GitHub is what we’re starting with, and it allows the community to help you complete your tickets. I mean, that kind of happens already, but what we’re trying to do is add an incentive to allow the community to have a reason to complete your issues and help you get more of your work done. Or on the developer side, it can help you find work easily.
Drew: So the way it kind of came about was… Just a quick story here from my own use. We do a lot of WordPress plugins for PayPal, WordPress and WooCommerce plugins. So we have to maintain those and develop feature requests, bug reports, things like that all the time. On GitHub, it’s open-source, it’s a free plugin. And there were times where I would come in… I loved it when I would wake up in the morning, sit down at my computer and, “Oh, look, there are support requests that came through.” Somebody in the developer community had been using our plugin, found one of our existing issues and just completed it for me. I didn’t have to talk to them. I didn’t have to interview them. I didn’t have to give them any information. It’s just, “Hey, they saw the issue. They fixed it for me.” I merge it in. It was done. That’s beautiful.
Drew: So I wanted more of that. The incentive they had is that they were using our plugin. They happened to run into the problem, and they happened to have the ability to fix it. So they went ahead and did it. There’s a lot of other issues that people who aren’t using our plugin would have the ability to fix. But since they’re not using our plugin, they don’t really have the incentive to do it. So the whole idea here is to give them an incentive where we can add a bounty or fund an issue. This particular issue might be worth $5 and another one might be worth $100 or whatever the case may be. Then developers all over the community can go in there and knock them out, submit pull requests, and I’ll just payout when I accept their pull request. So that means I’ve reviewed their code and I’m happy with it.
JC: See, that’s really cool. That kind of gets my tech tail wagging so to speak because I love… What I think is really cool, the simplified version of my head is essentially you’re crowdsourcing your coding, right? You’re crowdsourcing the support tickets from a technical standpoint basically. Right?
Drew: Yeah. Yeah. Exactly. In fact, that term specifically, it’s not there as of today, the actual crowdsourcing, but we’re adding that where we can have… Right now it’s just if I own the project, I can add a bounty or add funding to a ticket and then somebody can complete it. But again, with the case of our plugins, for example, there’s a lot of users out there and a lot of them might be willing to put a dollar or $5 or whatever towards. So what we’re adding right now, it’s not quite there but it’s coming soon, is the ability to have multiple bounties on a single issue. And then that would be more of a true crowdfunding or crowdsourcing.
Drew: Right now, we’re kind of, I guess, crowdsourcing for the developers using GitHub to do that. But crowdfunding will come here soon where you can add multiple bounties. And then again, the idea will be in our example, with our plugins, we can have the community fund the issues and the community complete the issues. So we’ll just manage the plugin itself. But hopefully, the community can knock out a lot of that work for the crowd-sourcing.
JC: How big of a fix is it? So for example, like if you had a plug-in company, how many issues do you see on average that they have outstanding, that they could use this help with? I mean, is it like five or six? Is it hundreds? Is it thousands? I mean like how big of a demand is really sitting out there for what you guys are helping people facilitate?
Drew: If it’s a relatively popular plugin, there’s usually going to be, I would say in the hundreds, if not thousands, of issues in somebody’s repository. Now that depends on how long they’ve had it running. Over time, you have your plugin out there for a month. You’re not going to have a lot of feedback yet, but if you’ve had it out there for years, you’re going to get a lot of feature requests and a lot of small bug reports, bigger bug reports. And over time, you’re prioritizing things, your backlog just gets built up with lots of little stuff that’s important. It needs to be there. It needs to be done, but it just never quite makes a priority. So that ends up being hundreds or thousands of tickets. Those are a perfect type of thing where the community can knock those out for you if you just start placing bounties on them.
JC: Let’s say there is no community. Let’s say there is no GitCommit, a plugin that, let’s say, has a hundred outstanding tickets. If they don’t have any other help other than their internal resources, how long do you typically see…. How long would it take them to get to through all hundred? I know that’s kind of a loaded question, but on average, how long do you see these outstanding, right? It’s kind of like seeing those houses on Zillow. This house has been on the market for like a year. Okay. So how long are these tickets typically outstanding that aren’t being solved because they don’t have the internal resources typically to do it?
Drew: I mean, that is kind of a loaded question. It’s hard to answer that one because it’s pretty subjective and it’s very relative to a lot of things. But a lot of them will sit on there for months or years even sometimes just because they’re not getting the attention. Again, they’re important. They need to be there. There is an issue created. It’s like someday we’d like to do that, but they’ll just sit there forever. Now, the more important stuff, the stuff that the internal team is focusing on, you’re usually closing a ticket if not just one day. If it’s a small ticket, then it might take a week or a month for a bigger project, maybe a few tickets to have them done. But again, during that month when you’re focused on those tickets, you’ve got lots of other little tickets getting out into your backlog from your customers or your users. So it just continues to kind of load up. Again, depending on what exactly the issue is and how big of a task it’s going to be, it’s kind of hard to say how long it’ll sit there.
JC: So then I imagine GitCommits community grows, the more it grows and these bounties, these $5, $10, $100 dollars, whatever the company believes it’s worth to get these solved. I mean, is it crazy to say that if someone had a thousand open that if your community was up and running huge, that it could be done in a day or two days or week or month? I mean like how fast if… Let’s say fast forward. Because you’re a startup, correct? Right?
Drew: Yep.
JC: So fast forward when the community has grown and it’s feeding itself, so to speak. If a new plugin or any kind of company comes in with, let’s say, a thousand tickets. They just now are open to this or whatnot. How long could that be knocked out? I mean, how fast would that backlog be taken care of?
Drew: I mean, that’s again, just kind of guessing here, not necessarily… Think about the community. There are tens of thousands of developers out there, if not more than that. Just a lot of them are waiting, looking for work. So if you had a repository of a thousand issues and then you joined GitCommits and you threw all thousand of them up there with whatever bounty or even half of, whatever the case may be. If you had them all funded, I mean, shoot, depending on exactly… If they’re smaller tickets and get them thinking in the future, we’ve got this platform running, we’ve got a lot of developers actively joining this or jumping on the site every day to browse the issue library and see what funded issues they can knock out. I mean, if you had a thousand and we had a few thousand even developers ready to do it, they’d knock them all out. I mean probably a bunch of them in just that day, but I mean, a couple of weeks, I would say, you could have all those knocked out with a lot of traffic in the community.
JC: And that’s just crazy to think about, because it almost sounds like… And I hate comparing new companies to existing ones, but I think it gives a frame of reference. You know when people said like, “The Uber of”? I hate that, but I get it. Yours kind of sounds like the Fiverr of coding issues, of solving those tickets where you got a community of people who can knock it out fast, easy, but it sounds even easier than Fiverr because in Fiverr, you have this community of people and you have to reach out to them to say, “Here’s what I’ve got.” Whereas with yours, it’s just sitting there and anyone who wants to come take a look at it can just start on it right away. Is that right?
Drew: That’s exactly right. That’s kind of what, again, with my own example. When we’re doing our plugins, the first thing we do, no matter what is create our GitHub issue. That’s our management system. That’s where we put the details of what the problem is, what needs to be done. Here’s all the resources you need to fix it. So all that info is in that ticket. Then from there, I’d have to go to Fiverr or Upwork or any of these other popular job places, post a job there, invite people or wait for people to apply. Then go through all those applications, interview them, find somebody, give them access, all those steps. I can eliminate all that. I’ve already done the GitHub part. I’ve created my issue. It’s now out there in the community. If I go ahead and fund it on GitCommits, I’m done. Now, GitCommits can take over letting the developers come and I can move on and do whatever else I need to do. And in theory, the next day I might wake up and boom, some of my issues have been completed. I don’t even have to talk to anybody.
JC: That’s crazy. How do you do quality control? Like if an audience member is listening and they have these issues that they have out there, they might be thinking, “Well, okay, well, what if somebody says they fixed it, but it’s not done correctly?” How do they know that the issue was actually fixed so they can pay that out?
Drew: Sure. Again, what we tried to do with this as follow the natural Git workflow as much as possible. Again, you’ve created your issue. You’ve got it on GitHub or wherever the case may be. A developer comes along and they commit their code and submit a pull request to you. So in general, you’ll have some sort of a team that’s going to review those pull requests and you’ll have your internal team that’s merging that code. So again, that happens regardless of where the work came from. Basically, the simple answer is you’re doing a review, and until you actually say, “Yes, this code is good,” and you merge it into your repository, that’s when it pays out. If you don’t merge it because you did your review and it was no good, then you don’t pay anything out. And of course, you can communicate back and forth if you find a problem, just like you would naturally. You’d let them know, “Hey, I reviewed the code. Everything’s good except for this one piece,” whatever the case may be or, “No, it was no good at all.”
Drew: You communicate and then once they’ve fixed it up and you’re happy with it so that you’re willing to merge it, that’s the point that triggers the payout.
JC: That’s really cool. Right now, as we’re recording this anyway, we’re still in the middle of a pandemic, unemployment is really high. How is GitCommits either helping with that… I mean, how do you see that integrated into what’s going on right now between high unemployment and pandemic stuff, you’re working from home? I mean, it seems obvious, but I want to see what your take is on how this can be a part of a very large solution.
Drew: Yeah, sure. Basically, a lot of people now are sitting at home trying to figure out what to do with how they can do their own business. They’re taking this time to finally start their own thing or finally learn to code or whatever they’re wanting to do. As more people are looking for that work, we’ll have this place that you can just easily go. And again, in the future, when we get this ball rolling here, all these people that are sitting at home looking for development work to do can just go to GitCommits, browse the issue library, and there’ll be funded work. They’re ready to go. You don’t have to apply for it. You don’t have to do any of that stuff. So that’s one side.
Drew: I mean the others on the flip side of it, if you are the product owner, it gives you a chance to get that thing started. You’ve been working your full-time job, you come home, you got family, it’s hard to kind of do your thing. Now, people had that free time and maybe they’re starting. They did decide to go ahead and build their plugin or they needed help getting this thing launched. Well, create your issues, get it up there on GitHub and let the community help you get that thing done. So yeah, just having that time now to get those issues created or do the work, it’s just kind of a perfect fit because you can do it from anywhere that you have a laptop and some internet access and get your work done.
JC: Yeah. Get your work done. I like that. Does this only work for plugins, or is there any other types of companies or softwares that this either can now help or in the future? How does that work?
Drew: Yeah, basically it works for anything that you can do with Git in general. So the plugins are just an easy example, and that’s just what I use myself, kind of how this thing was born. But I mean, people use Git for all sorts of stuff, whether it’s open-source free projects, private repositories, or even graphic designers sometimes use Git to do version control on their graphics that they’re creating. So if you had a repository with some Adobe illustrator artwork in there or something like that and you wanted to have the community help you knock out some issues with that, you could use it for that. So again, anything that you can use Git for version control, you can put it on GitHub or any of those repositories, and then that would work with GitCommits.
JC: That’s really cool. Where do you see… In the spirit of the future of biz tech, this is where it’s at now, if you had to fast forward in your head five years from now and not necessarily just GitCommits, but what you’re doing sounds really unique to me. I haven’t heard of another platform out there that allows this to work in the manner that yours does. Especially what I like about it, again, is that a company can just put all their issues out there, and then it just happens. People are already… They take a look, they code it out, it gets accepted, they get paid. I mean, it’s simple. Even the company doesn’t even have to reach out or anything. And that’s innovative in itself.
JC: But first question being is where do you see GitCommits in five years? And then the second question is, it seems like you’re one of the first, if not the first, to this arena, but there will be those who follow, which can be good. Right? It forces innovation, it keeps people nipping at your heels so that you can always push that envelope. Where do you see even just this industry idea of going in five years, let alone GitCommits?
Drew: Yeah. So basically I guess I would say the goal is to turn this thing into kind of the place where developers go to either get work done or find work to do. And just simplifying the whole thing. If this thing’s all running in five years from now, we’ll have loads of issues in there. Any time anybody ever has a job that they want to do, “Hey, just go to GitCommits and browse your issue or browse the issue library, find some issues, knock them out.” So again, just eliminating the whole interview process, payroll, onboarding new people into your platform, and creating user accounts and whatever product.
JC: Yeah, because who cares? If they code it out and it works, then it works. Who cares who they are or where they’re from?
Drew: Exactly. You don’t need to really know them. Now, naturally, if the same person is committing a lot of code for you, you’re probably going to start communicating with them and maybe start working more directly with them. So it’s an avenue for that as well. It kind of almost becomes the interview process.
JC: Yeah, that’s true.
Drew: Where they are completing some tickets for you and you see, “Oh, hey, this guy’s doing good. He’s knocking these out quickly.” I’m going to reach out to him and say, “Hey, are you interested in coming on as a more dedicated user? Or would you just prefer to keep…” Probably still do the same thing with the platform, but you can bring them on and just assign them directly. That’s one of the things in GitCommits. There are various project types, so you could have just a contest or anybody can commit code to it. Or you can say, “No, this is a traditional one. I only want this one person working on this.” So once you’ve established that relationship with somebody, you could just create your tickets and just assign them directly to them.
JC: Well, and that’s cool for the business. But even from the other side of it, the developers, it acts as their application, even if there’s no one hiring, right? They can just say, “Well, hey, I want to go work for this company. So I’m going to slam out a ton of these issues today and this week or this month or whatever, and try to get my foot in the door.” Right? So this also seems like it’s almost like a backdoor into getting some sort of full-time employment or contract with a company you really like. Because if they have issues outstanding and you’re like, “I want to be a developer or coder for them,” you can just go on there and just start. I mean like, literally, like you said, without even the interview process in the beginning anyway, and then that can develop into that relationship where they might say, “Hey, this guy has slammed out a hundred things for us. He does it fast. He does it well. It all checks out. Let’s hire him.” You know what I mean?
JC: What I love about it is I see both sides. There are so many advantages to both sides of this, which I think is really cool.
Drew: Yeah. I mean, back to that, it becomes their application. It becomes their resume because they also have a history now. Like on GitHub, for example, when you commit code to somebody, it logs all that. It’s like a social network for code. That’s what GitHub is. So now you’ve got a profile that shows I’ve had 5,000 code commits accepted, and that looks good on you. So not only are you doing the work, you’re getting paid without having to go through interviews and all that, but you’re building that resume out and of course, right now, GitCommits itself doesn’t have a lot of that. We’re leaving it up to GitHub right now or Bitbucket, GitLab, et cetera. But we’ll start tying a lot of that in. We’ll have review systems and we’ll kind of curate all that data together and consolidate it in one place so that you’ll have like a GitCommits profile where you can see all your GitHub and Bitbucket and GitLab history in that one place and turn that into your resume basically.
JC: What would be the advantage of a developer or a company listening right now to get on board with GitCommits? By the way, does it cost anything? How does it work? Is there a set of fees? Is it just free and everybody just does it? How does the money flow and who pays what in that sense?
Drew: Yeah. So basically, there are two sides. There’s a product owner or whoever has the software, has the Git repository that you’re managing. And then of course you have your developer side. So for the product owners, it’s totally free. You just post your issues or you add your bounties. The only payout you make is the amount you choose to pay as the bounty for that specific issue when somebody completes it. The developer side, when they complete an issue, we do charge a fee on that side. Right now, we’re starting at 5% and then the PayPal fee would be different. The total fee for the developer has got to be around eight, maybe up to 10% at the most right now, which is still about half of any of the other things that we’ve mentioned already when you’re trying to post jobs and you can get work done through those avenues.
Drew: So again, on the product owner side, totally free other than your bounty that you’re paying out, which you would be paying for the work anyway. Then on the developer side, work that into what you’re willing to do. But yeah, when you complete your job and you get paid, you’ll pay the PayPal fee as well as the GitCommits’ platform fee.
JC: Got it. Okay. So there’s no entry cost. It’s just the only people paying is only after they’d been paid basically.
Drew: Right. Exactly. Yeah. There’s no payout until either work is done and you’re paying out just that work. Or if you’re a developer, you don’t pay anything until you’ve received money and then you’re just paying a fee out of that. Now over time, if you’re doing a lot of volume on the platform, we’ll structure fees differently and you’ll pay a lesser amount if you’re doing more volume.
JC: Sure. Some sort of tier system.
Drew: Yeah, exactly. So we’ll build all that out. But yeah, right now, like I said, we’re coming in about half of what the other guys are doing right now and doing it a little bit differently. So we think it’ll be a good tool.
JC: Let me ask you a personal question. I’m just curious, it’s going to be completely unrelated, but what did you want to be when you grew up, so to speak, when you were a kid? And then how did that, if it is the same as what you do now, great, but if not, how did it change? What was that point where you’re like, “Okay, I’m going to do this now instead”? What was your childhood dream versus that evolution to what you do now?
Drew: I was kind of lucky in that sense. I never really had to go through that what do I want to do stage? I mean, I guess when I was super young, 10 years old, I was, “I’m going to be an athlete.” I used to be pretty good, not so much anymore. But yeah, then I mean about, I guess it was maybe 12, 13 is when I started kind of getting into computers. From that time on, it was just, “I want to do something with computers.” I didn’t really know what, I just knew computers were my thing. Over time, turned into graphic design stuff and then just kind of fell more into coding. That’s what really grabbed me, just the ability to tell the computer what you want it to do and it just does exactly what you said and nothing more, nothing less. So that was just pretty fascinating to me. And dived down that rabbit hole and here we are today.
JC: You’re probably one of the few people I’ve interviewed or talked to where literally their childhood dream, it evolved into literally what you’re doing now, which is fantastic. Mine was not. Mine was kind of like that after college dream, and then I’m still doing that, but that’s challenging. That’s a big one.
Drew: Yeah, I was lucky.
JC: I am curious. What is the best piece of advice you’ve ever been given business-wise? As something to share with the audience, some words of wisdom that were passed to you over the years.
Drew: It’s kind of a funny answer, I guess, I’ll give here. Because unfortunately, I’m not doing a very good job of following that best piece of advice, which is, “Don’t grow too fast.” And I find myself doing that all the time. I get all these ideas and then I want to put a new team together and do this and I get overwhelmed with it sometimes. So I need to step back and follow that advice. That really is the best. I honestly can’t even remember who it was that told me that because it was a while ago now. It was kind of when I was first getting started with all this. But yeah, I just remember him saying, “It’s easy to want to do a whole lot of stuff, but take a step back. Don’t grow too fast. Get yourself going piece by piece.” I’ve been good at that with some things and I’m kind of falling out of it. I’m glad you asked that. You reminded me of that good piece of advice. I need to get back to that.
JC: Keep you on track
Drew: Yeah, exactly.
JC: Well, this has been awesome, man. Is there anything I haven’t asked you yet that you think would be a benefit to the listeners to hear? I mean, is there anything that you want to close with?
Drew: Just one more piece of functionality that I didn’t really bring up yet. On the other side of all this, I mentioned the bounties and I mentioned placing a value on your bounty. As a developer, we have an extension for offers that you can install. So if you’re on GitHub and you’re browsing all the issues on GitHub, and maybe it’s not even on GitCommits yet because that product owner doesn’t even know about GitCommits maybe, you can install the offer plugin and you can actually submit an offer. “Hey, I’m willing to do this issue for a hundred dollars,” or whatever the case may be. That we’ll introduce or send a message to that product owner and show them, “Hey, you’ve got a bouncy request here or a bounty offer of a hundred dollars.” So that’ll introduce it, and then you can counteroffer, counter and back and forth until you agree on a price. That’ll just be a tool for developers that they can use to find work even when GitCommits may not necessarily have a perfect issue there for them to start on.
JC: So they can just install this plugin or this extension on their browser. And even if the company or the plugin that they want to help out, isn’t part of it, it will still send them these messages regardless so that they could get it, right? Almost like introduces and prods the company that has the issues that like, “Hey, I’m a developer. I want to solve this for you for a certain amount of money.” And I don’t even need to have any kind of weird intro. Like your extension creates that communication between them automatically.
Drew: Yeah. Let’s say I have to GitCommits extension in my browser, I’m on GitHub. I find a ticket that, “Oh, I can do that.” So I might, say, make an offer. When I do that, it’ll just put a comment inside that issue notes, so the product owner will see that and it’ll have links out to GitCommits, et cetera. So that’ll kind of inform that product owner, “Oh, Hey, what is this GitCommit? I got a bounty. What is this?” So it’ll kind of teach them about it, and then also introduces them to that person that’s willing and ready to do that work for them. So then they can go ahead and either accept it or, again, counter back and forth until you agree on a price and then get going. Yeah, the idea there is that even if the GitCommits issue library isn’t necessarily full or if you’re not finding something there that you need, GitHub itself has thousands of issues out there. You can absolutely find something.
JC: What I like about that is there’s a virality component to what you just did there. What’s weird is usually things that are viral are created by the source. Whereas with this, it kind of sounds like the virality is in the hands of the users. Because if I’m a developer and I want to go help with this issue on this particular plugin company, but they’ve never even heard of GitCommits or this platform before, just by me having this extension and commenting on theirs, it’ll automatically not only show them and communicate with them that I’m willing to do this for a certain amount of money, but because it’s in the comments section, then everybody can see it. Right?
Drew: Yep. Absolutely. And also just-
JC: That’s absolutely brilliant. I mean like legitimately brilliant because I mean just again, tech tail wagging right now. I love that component because you’ve decentralized the viral component of it. Right? You allow even just that person using it automatically shows other people that it can be used and what it is. That sounds kind of like a really cool snowball effect you’d have going there.
Drew: Yeah. That’s exactly the idea. We want to get it in the hands of a lot of developers and get them making offers.
JC: Well, that’s awesome. Drew, listen, I want to thank you for being on the show. I interview a lot of people, but I got to tell you, I really like the really unique stuff. I don’t usually interview startups, but because it’s the future of BizTech and your idea is so unique and almost kind of that first to market concept, I couldn’t resist. So thank you for coming on the show. How can people listening reach you or the company, a website, email, LinkedIn, stuff like that? How can people listening get ahold of you if they need to?
Drew: Yeah. The easiest thing I would say, just go to GitCommits.com. G-I-T Commits, C-O-M-M-I-T-S.com. There are contact channels there. You can find all the social links and everything on the website. So that’s probably just the easiest way to go. Reach out directly through the contact there or through the social channels. And I’d love to answer any questions you have.
JC: Awesome. Well, listen, thanks again so much for being on the show. I look forward to having this air for everybody.
Drew: All right. Thanks a lot for having me. I really appreciate it.