INTRO: Welcome to Apply Filters, the podcast all about WordPress development. Now here’s your hosts, Pippin Williamson and Brad Touesnard.

BRAD: Welcome to Episode 61. This time Pippin and I will be talking to Devin Walker. We’ll get into what Devin does, we’ll talk about collaborating on open source projects, and we’ll discuss the GitHub pricing changes. But first–

PIPPIN: This episode is sponsored by WP All Export, which is a powerful export plugin for WordPress that provides a simple drag and drop interface to make it easy to export data from posts, pages, users, or any custom post type in WordPress, such as WooCommerce products or orders, to an XML, CSV, or Excel file. The plugin allows you to organize a file however you want, include or exclude data, so that you can build the precise CSV or export file that you need.

WP All Export also has a sister product called WP All Import that allows you to then import that data back into WordPress. If you want to export data, make some changes to it, and then import it back in and make updates to your data, you can do that very easily.

You can find out more at WPAllImport.com/export. Be sure to thank them for their sponsorship.

BRAD: Awesome. Thanks.

PIPPIN: All right, so we have Devin Walker joining us today. Say “hi,” Devin.

DEVIN: What’s up, guys?

PIPPIN: Awesome to have you on the show. We want to talk about a few things today. First, we want to hear a little bit from you about what you do, how you got started in development, et cetera. Then we’re going to get into some other subjects. First, if someone was to ask you what you do, what do you tell them?

DEVIN: I would say right now I am a WordPress plugin developer.

PIPPIN: Okay. For people that are other WordPress users or developers, what are the products that you build or what’s the company that you’re involved with?

DEVIN: Definitely. My company’s name is WordImpress, WordImpress.com, and our flagship product is called Give, and it’s a WordPress donation plugin. We have other products as well on the WordPress side. Our second is Maps Builder Pro. Then we have a WooCommerce extension called Quick Checkout.

PIPPIN: Give us a little bit of history on WordImpress. I believe that there are a few other people involved with that, so maybe who are they, how long has WordImpress been around, and maybe how did it come to be?

DEVIN: Yeah, definitely. When I stepped out of kind of the agency world back in 2011, 2012, I wanted to focus more on WordPress and do freelancing. At the time, I only had the domain name Wordmpressed.com. I didn’t get the “WordImpress” without the “ed” at the end until later, but I just started as a blog where I would write tutorials and code snippets about what I found out when I was working on various client sites in my freelance gig.

I did freelancing for two to three years. I had some jobs at that point. I wanted to develop a plugin and see if I could get something working there. The perfect opportunity was with the Yelp API. There wasn’t really a good plugin to pull in reviews for restaurants, for other websites, for any business, really, on Yelp.

I went and set forth to build Yelp Widget Pro, which is still in the WordPress.org repo. People seemed to like it. Then kind of after that I was addicted. I came out with Google Places Reviews and just continued doing a couple more little widget plugins like that, built a little business out of it and continued blogging. I had the opportunity to get the domain name without the “ed,” so I paid for that, redesigned it a couple times, then finally had enough revenue generated to kind of start a business out of it.

PIPPIN: When you started, you said around 2009 or 2011?

DEVIN: 2011, 2012, yeah.

PIPPIN: What was your first version of WordPress that you started actively working on?

DEVIN: Actively working on was pre-custom post types. I believe it was 2.8, I think, was the version I started, so I started with WordPress around 2009.

PIPPIN: I think that’s exactly when I started. Okay, so you guys have several of your large projects now. You have Give WP. You have WooCommerce Quick Checkout. You have Maps Builder Pro. Are those the three big ones now, or have there now been others as well?

DEVIN: Those are the three big ones. The biggest one is Give. That’s one we are spending most of our time on and focusing on building out even more so. We really like the nonprofit space, helping people out, helping people raise money. There have been lots of great stories of people using our plugin to raise funds.

For example, there are three college students riding their bikes across the East Coast right now to raise money for women’s education in Africa. That’s just one of a couple stories that we’ve highlighted. It really is kind of like a good thing to see that, and I like that space a lot.

PIPPIN: Something I’ve enjoyed watching, I’ve kind of paid attention to Give since it first started, and I’ve really enjoyed watching you guys not only build a good product, but also highlighting those success stories with it. I think that’s a really valuable and really excellent way that produce creators can not only take pride in their work, but also help show how it’s making a difference, so props on that.

DEVIN: Thanks, man.

PIPPIN: With that, why Give? What is it? What led you guys up to building Give and to start focusing on nonprofits, donations, and stuff? It seems like kind of an interesting jump to go from Yelp Reviews, Google Places, which are definitely very similar types of products, then going into e-commerce with the WooCommerce Quick Checkout plugin, and then going to Give? Is there some kind of timeline or sequence of events that got you there, or was it just following things that you guys were interested in?

DEVIN: No, there was definitely a sequence of events that led to the creation of Quick Checkout, first of all, which morphed kind of into the bigger picture of our own platform. When I was freelancing, I was doing a lot of work for this agency called SoundPress. No relation to WordPress, except for they used WordPress a lot. They primarily focused on churches and nonprofits as well.

These nonprofits would always have these specific needs. For instance, the checkout has to be on one page, and you need to donate directly on that page. We’re like, “Okay. We could use Gravity Forms,” but they want all the nice reporting and all that. At that time, there wasn’t much of a solution for Gravity Forms on that, so we said, “Okay, we’ll use WooCommerce, and we’ll figure out a way to get the checkout on one page,” kind of make a landing page for people to donate right directly on that page.

We developed kind of a prototype, which was the early versions of Quick Checkout, mainly to accept donations on these websites. It worked pretty well. There are a number of sites still using it to collect donations, but it still didn’t fulfill that need.

On the backend, they’d go in. They’d see an e-commerce platform. They’d see product where they would want it to say “Donation Form.” They want it to say “price” anywhere, so we were really taking this behemoth of an e-commerce engine and forcing it into something that it wasn’t really and the client, ultimately, in the end wasn’t too happy with.

They wanted something that was a little more tailored to their situation. At that time, there really wasn’t anything like that that we were happy with. Being a long-time fan of yours and seeing the code base that you’ve written and developed over the years, we thought it was kind of a perfect segue into what we wanted to create with Give.

PIPPIN: I can definitely sympathize with that experience of using a product, using it for a purpose other than it was created. You mentioned how WooCommerce for donations, while it worked perfectly fine, it’s not built for that. And so, the client goes in and looks and says, “Well, what’s up with all this product stuff? I don’t need that.”

We had a very similar experience in EDD where we had people using it for crowdfunding, and you had all of this digital download stuff and other product related features, and they just didn’t fit within that model. That reason right there is one of the reasons I was really thrilled when you guys created Give because there really wasn’t a product that fulfilled that niche in the WordPress market.

Give has been very successful for you guys. It’s a great product. You guys have been expanding it a lot. Can you tell us a little bit about the business model of Give? It’s a free plugin on .org. Tell me the rest of the story.

DEVIN: Definitely. We set it up similar, a free-based plugin on WordPress.org, like you said. It’s not cripple-ware at all and not lacking any critical features, so it’s very robust. It includes PayPal standard and offline donations out of the box. But, wherein you need additional functionality, you want to accept credit cards on your site, maybe you want to create subscription donations, or generate PDF receipts, then you’re going to come to our site and purchase either an add-on, or we recently rolled out bundles. You can sign up for a number of our bundles and get access to all of our add-ons, which is new as of two weeks ago, and people have really been liking that ability to kind of get everything under one payment.

Then you have access to the features you need and, as well, you can access our priority support from there. It’s been really successful for us so far, and we think people will like the way we’re selling it.

PIPPIN: Now, I believe–correct me if I’m wrong–Give was actually originally a fork of EDD. Is that correct?

DEVIN: That is correct.

PIPPIN: One of the things that I like about Give is–for a moment, ignoring everything that Give is built for: the donations, et cetera–I think it’s great because, in my mind, it’s the perfect example of what a fork should be. I remember when you guys first launched Give, there were some negative reviews and comments saying, like, “You guys forked EDD. What are you doing? Like, that doesn’t seem right.”

In my mind, that was a little unfortunate because I think it’s actually the perfect example of what a fork should be in that there was EDD, which provided this platform, and you want to do donations, but they weren’t quite the same thing, and so it’s actually doing exactly what a fork should be in going a different direction but starting from an existing foundation. Is that kind of the way that you guys looked at it as well?

DEVIN: Absolutely. We thought about it for a while, to be strategic in the way we built this, and we had a very small team, me primarily being the developer on it, and I decided, “How can we develop the best product in the shortest amount of time?” EDD was nearly identical to what we wanted.

We did some different directions on some of the code base. For instance, for the settings, we used CMB2. Then we used some of the templating from WooCommerce and some tidbits from Gravity Forms and Yoast….

PIPPIN: That’s awesome. Actually, it’s not just one fork. It’s like four forks combined.

DEVIN: Yeah.

PIPPIN: It’s great.

DEVIN: Plus our own little dash of code in there, here and there.

PIPPIN: As the product continues, eventually it won’t even be recognizable as a fork.

DEVIN: Right.

PIPPIN: Is there still overlap with EDD, WooCommerce, Gravity Forms, and each piece that were forked from the other projects? Is there still overlap there?

DEVIN: Yes, mainly with the templating of WooCommerce, and there’s a lot of overlap still with EDD. For instance, we’re upgrading the payment system to your new payments class, a forked version of that, because it’s just a so much better way to handle payments, as I’m sure you’ve found out in EDD.

PIPPIN: Yeah.

DEVIN: We look at that, and we pay close attention to your repo and submit a PR here or there where we can, but things like that really catch my eye and say, “Ooh, well, this makes me really happy that we do share such a similar code base.”

PIPPIN: This is really leading nicely into what we really want to talk about here with you, Devin, and that’s some open source collaboration, and so collaboration between open source projects. EDD is open source. Give is open source. I think Give has provided a lot of really nice examples of how open source projects can work independently, but still collaborate, like the payment one you just mentioned.

Recently, in our last major release for Easy Digital Downloads, we introduced a new class for a payment object, so EDD Payment. This completely reworked how payments are stored in the database, how you interact with them, some helper API methods, et cetera. The fact that you guys are able to now take that and apply it to Give is awesome.

We recently had some experiences working together on an add on add-ons. Can you kind of tell us about the story, for everybody that’s listening, the recurring payments experience?

DEVIN: I thought it was a great experience. When we released Give, we didn’t release it with recurring donations or, in your case, subscriptions. People were really knocking down our door for that. We looked at the current EDD add-on and the state that it was in. It wasn’t really release-ready, in our opinion. It couldn’t handle certain functionalities that we deemed were necessary for our customers, and we knew what they would expect.

We reached out to you, and you said you had big plans for this. We wanted to make sure we could accelerate that process as quickly as we could. It was a high priority number one for us.

What did was we collaborated together on specific portions of the recurring subscriptions extension, which is now available for Easy Digital Downloads, and we basically footballed back different functionalities, and it worked out really well, I thought. We released it a lot faster than we could have on our own. That’s a definite positive right there.

PIPPIN: It was a cool experience, for sure. I think one of the reasons that we were able to do this, have you guys help us build the new recurring payments plugin for EDD while simultaneously building it for Give, was because the platforms share so many similarities due to the forked nature of it. I think it was a great experience being able to have outside developers working on a similar project, contribute to the same code base, and go in both directions, so you guys contributing to us; we contributing to you. I think it’s something that open source projects can really take advantage of, especially when they share similarities.

Do you think that there’s any significant challenges or anything else that you want to throw out there?

DEVIN: One thing that I’ve always kind of thought about when we released last year at WordCamp, a month after WordCamp San Diego 2015, and your response was very positive. There was a minor flack from the community, not much at all. For the last part, it was positive. But, if you decided to kind of go a different direction and kind of give us, I know you wouldn’t, but if you, for instance, had thought about that, and I don’t think we would have been where we’re at today without your support and your backing. Actually, I know I wouldn’t. I just kind of want to commend you for that and say that we’ve always continually thought about that and been thankful for that.

PIPPIN: Well, absolutely. I think that’s one of the beauties of open source that we get to take advantage of. I think it should be recognized. That’s having someone fork your work, it doesn’t matter whether it’s a little project or a big project, whoever it is, is a great compliment, and I think it’s silly that people get so up and arms about it sometimes. People champion open source all the time, and then the moment that it’s actually utilized and split into a new project, sometimes people get up and arms, and that’s too bad.

DEVIN: Yeah.

PIPPIN: Let’s go back to our collaboration process and talk a little bit more about what that looked like. We had a recurring payments plugin that we were working on building, and you guys had a Give WP recurring payments plugin that you were working on building. They were kind of built up at the same time. What did that look like?

DEVIN: Well, I think once you had that base recurring subscriptions class in place, it really let us run with building out various gateways. For instance, it let us build out PayPal. I think we did Authorize, at least the base of Authorize, too. Then you guys were able to do 2Checkout and I believe WePay is in the works currently.

PIPPIN: Yeah.

DEVIN: Stripe as well. I think we both kind of did a bunch of Stripe. Once you were able to kind of get that backbone for us, it really allowed us to kind of run with it. Then we knew we wanted emails. I looked at how software licensing handled things like license renewal email reminders, and we wanted a similar thing, and Give subscriptions or EDD subscription payments and so that was just a perfect way to fork another extension that you had already written and repurpose some of that code for some of the needs of this subscriptions add-on.

PIPPIN: Probably most importantly was collaborating to build the backbone and then being able to split off from there and build everything that was kind of unique to each project, so you guys have things that are unique to Give. We have things that are unique to EDD, but we share that same backbone. That’s really where collaboration happened and was apply to apply to both projects equally.

DEVIN: Right. Before that was ready, we were really kind of hard pressed to find ways we could effectively collaborate. But, as those different classes came into place and we were able to extend them, it really let us kind of fly after that.

PIPPIN: Did you guys ever use sub-modules or anything like that to sync changes over, or was it just manually copying back and forth?

DEVIN: No, not too much. It was a lot of comparison, pull requests, things like that.

PIPPIN: This is kind of an open-ended question, but is there something here that you think listeners can take as maybe a tidbit or tip of the day for helping with open source collaboration and collaborating between two similar projects? Anything at all that you learned or you think that we learned from this process? I know this was the first time that I had ever done this with someone else, and so it was definitely a learning experience for me.

DEVIN: Well, I mean this is kind of obvious, I but I think communication is really important. The fact that I was able to ping you on Slack, or we got on a Hangout, I was able to record your explanation of how the EDD subscription class works, and then I was able to go back and refer to that when I was kind of questioning some methods or wondering how a certain function worked. Just having that knowledge base and being able to go back and forth and collaborate on GitHub issues as well was really helpful.

PIPPIN: I think that, for me, the two most important things that you just said there is, number one, making sure you have active communication, but, two, making sure there’s a history of that communication that you can reference later on. I definitely found that to be very, very true not just in cross-project collaboration, but also within our own teams and if we’re working with external people. Making sure that any communication you have, number one, that it’s open and easy to have, but, two, that it’s accessible later on, so whether the discussion happens in GitHub issues or recorded conversations or where have you. It doesn’t matter as long as you can go back and reference that is, I think, very important.

DEVIN: Right, which is Slack’s whole business model, right. I should probably go sign up and pay for it now.

PIPPIN: Speaking of business models, maybe it’s time to go ahead and get into the next subject that we wanted to cover, which is related to GitHub’s new pricing that they announced yesterday. We’ve been talking a little bit about open source collaboration. GitHub, yesterday–GitHub obviously being a platform that is HUGE and is hugely used for open source collaboration–they announced their new pricing, and I think we all have opinions on how this affects, either positively or negatively, open source collaboration. And so, we’d like to get into this. Brad, we’d like to bring you into this conversation now.

BRAD: Yeah! I’m back.

PIPPIN: You’ve been sitting on the sidelines.

BRAD: I’m back for the drama now, man.

PIPPIN: All right, Brad, do you want to give everybody who is listening a quick overview of the pricing changes that GitHub made, for anybody who hasn’t seen the blog post from them?

BRAD: Sure. Yeah, it’s pretty simple. It used to be the pricing was based on how many private repositories you had. I don’t know the exact numbers, but if you had ten repositories, I think it was $25 a month or something like that. I’m pretty that’s what it is. The old pricing is still in effect. Everyone that’s on the old pricing can stay on the old pricing for now. I think they’ve guaranteed 12 months, at least, that the old pricing will still be around, but they’re not guaranteeing anything after that.

The new pricing is per user per month. If you have an organization, you can have unlimited private repositories, but you have to pay $9 per user per month or $25 a month for your first 5 users, which I just realized that’s more money if you have only got 2 people in your organization than $9 per month per user.

PIPPIN: Right.

BRAD: Very interesting. I think they are trying to make more money, it kind of seems, doesn’t it?

PIPPIN: Free — well, ultimately, that’s always a goal of a pricing change. Either you make it cheaper so that you get more customers because you can’t get enough, or you make it more expensive so that you get more money out of those customers.

BRAD: Yeah. Exactly.

PIPPIN: Private repositories are now free for personal users. You can have as many as you want. But, if you are an organization, the pricing that you pay for those private repositories is now a little bit different.

BRAD: Another thing we should probably clarify is what constitutes a user. I believe they just added this. I’m pretty sure the blog post didn’t have this information the first time I read it because I think they added this.

PIPPIN: I missed it the first time too. I found it in the FAQs later.

BRAD: Yeah, I think they may have added that after the fact. Anyways, a user is anyone that is a member or an owner of the organization. Anyone who is a pending invitation, so like if you invite someone to your organization, but they haven’t joined yet, it still counts as a user, which I think is kind of crazy.

PIPPIN: Ouch! That’s a little iffy.

BRAD: That’s crazy! Then, outside collaborators with access to one or more repositories and, to qualify what outside collaborators means, which I had to do, it just means the way you manage them is different, like via the UI, from what I can understand. An outside collaborator, you can’t add it to a team, like a team within your organization. If you have a team set up with access to certain repositories, it’s pretty convenient to just add someone to that team, and then they get access to all these repositories. An outside collaborator, you have to go to each repository you want to give them access to and add them as an outside collaborator to that repository.

PIPPIN: Right, which you know can be handy if you just want to give one person access to a single repository.

BRAD: Yes, it is. It’s super handy. That whole construct of an outside collaborator, I just assumed that it wouldn’t be counted as a seat.

PIPPIN: That’s what I would assume too, but that’s not true.

BRAD: But it’s not true. It’s not true.

DEVIN: I was thinking that somebody with write access to the specific repositories would be counted.

PIPPIN: That’s what I would have thought.

DEVIN: Not people who just read.

PIPPIN: If you were read only, then you don’t count.

BRAD: Oh, I never even thought about that. That’s a pretty fair — that would be fair, I think.

PIPPIN: But, the way I understand it, that’s not the way it is.

BRAD: That’s not what it is, though.

PIPPIN: Okay. I want to give my take on this, and then I’d love to hear each of your guys’ takes on how it affects you, what you think about it. I think there are some positives and some negatives to it. First, the positive is that for personal users, excellent. People that may have been paying $10 or $20 a month, now they’re paying zero or almost zero, and they have unlimited private repositories. That’s awesome.

From an organization perspective, however, there are some drawbacks. I went and looked at it. We have, actually, three main organizations. I have a couple of others, but we have three that we use. We have one for EDD, one for Restrict Content Pro, and one for Affiliate WP. Each one of them is separate, and they have separate teams. There’s a lot of back and forth. There are members that are on each of the teams, but anyway, they’re each managed separately in terms of billing is the main, important distinction.

We have a series of private repositories in each one of them. We have a lot of public repositories, but we have a few private as well. Up until now, it’s always been whatever the limit is for the $25 a month plan. For the last year or two years or so, I’ve paid $25 a month for each of my organizations, my three organizations so that we can have the 20 or 25 private repositories, whatever it is. And so, my monthly bill has been $25 a month for each one of those.

I decided, after the new pricing got announced yesterday, to go and see what the Easy Digital Downloads organization will cost with this new pricing if we don’t make any changes. I figured out that it will be around $600 a month, which is more than a 2000% increase for us.

DEVIN: Wow.

PIPPIN: That’s a little hard for me to stomach without having any added benefits. There are zero benefits of this pricing change for us, except for a 2000% price increase. I’ll tell you; I’m not particularly thrilled by this. One of the reasons why it’s so expensive for us is because we have a ton of outside contributors.

Devin, you’re a perfect example. We have you in our organization so that you can access the private repositories that we have related to, say, the recurring payments plugin, software licensing, et cetera. Now, you will cost the organizations $9 a month, as well as the other 25, 30, 40 people that we have in there that are both customers, other developers collaborating, and that they’re there so that they can submit an occasional pull request or bug fix, but are not necessarily working on it every single day. To me, that was pretty hard for us to accept.

BRAD: Yeah. It doesn’t feel like you should have to pay for those contributors, right?

PIPPIN: Right.

BRAD: That are not contributing every single day. They’re not part of your organization. They’re outside contributors.

PIPPIN: Right, exactly.

BRAD: Yeah, it doesn’t feel right. Just semantically, just saying the words, it just doesn’t fit. It doesn’t feel like it fits. It’s funny, though, because if you look at the value, if you just look at the value that you get out of GitHub. I thought about this before the pricing. I have thought about this before the pricing increase or the pricing change that we are paying not nearly enough for GitHub right now. I would have gladly paid ten times as much. A hundred times as much, that’s a stretch. That’s a stretch, right?

PIPPIN: I’m with you 100% there. Honestly, $25 a month for what we get is pennies for the value provided. I actually wouldn’t even have that much of an issue paying $500 a month because the value — we get more than $500 a month in value out of GitHub, easily. It’s more the principle of changing existing customers without changing the value for them to justify that change. Are either of you guys affected in similar ways?

BRAD: I’ll start. We’re not that affected. We’re not nearly as affected as much as you. The biggest impact for us is: I’ve got a WooCommerce software subscriptions that I’ve talked about on the show several times. Honestly, that’s actually where the outside contributors have come from, from people that have heard me talking about it on this show. Then they just send me a message. It’s a private repo because I don’t want us to have to support it. So, they send me a message, and I give them access to it. And so, I’ve got over a dozen people on there, which, for a project that I’m not charging for, I don’t really want to have to be paying $9 a month for 12 people.

PIPPIN: That’s costing you about $100 a month. Actually more. It’d be like $120 with the new pricing.

BRAD: Yeah. I’m just giving them access because I can, because why not share that code, right?

PIPPIN: Right.

BRAD: But, at the same time, I don’t want to make it publicly available because I don’t want to support it.

PIPPIN: Let’s say that you decide to — let’s say I find a bug in WP Migrate DB Pro, and you decide to give me access so I can submit a pull request. Let’s assume that that’s the only pull request I ever give you. You’re going to pay $9 a month for my access perpetually for that one bug fix.

BRAD: Right, but I wouldn’t have to pay perpetually, right?

PIPPIN: No, you wouldn’t, but that’s the way that it works. Just me having access to it, even though I’m not contributing on an ongoing basis.

BRAD: Right, so I’d give you access. You’d submit the thing.

PIPPIN: Then you’d kill it.

BRAD: Then I’d revoke your access, which also feels wrong.

PIPPIN: Yeah, it does.

DEVIN: Yeah.

PIPPIN: Devin, how about you? Are you guys affected by this?

DEVIN: Like Brad said, not nearly as much as you. I think we have 20 collaborators in our GitHub, and we’re on the $100 a month plan for, I think, up to 100 private repos. But, you know, I do agree we’re paying a little less than we should for it. It’s more than just a repository. It’s a project management system. It’s a social network, in a way, and it’s gamified as well. If you look at your profile page, I’m in a number of different organizations. I have their badges on there. It’s kind of gamified in that way.

I’m really worried that this is kind of going to stifle some of the collaboration a lot. If somebody has to go and allow PR to a private report, revoke access, you know, it’s just going to, over time, break down. I don’t think it’s going to be sustainable. I think that their vision of what a private organization is really isn’t in alliance with open source.

PIPPIN: No, I don’t think it is. A perfect example is what we’re going to start doing, I mean at least once we’re forced to change to the new pricing, is if a customer comes to us and says, “Hey, I found a bug. I’d like to submit it to you,” we’re going to say, “Send us a patch in the email.” Whereas before we would say, “Hey, what’s your GitHub user name? Not a problem. We’ll add you in. Great.” That’s just not going to happen any more, which I think is unfortunate.

BRAD: Yeah, so that is the biggest issue, right? Why don’t they just not do that and just charge us more for the users that are a part of our organization, that are not outside contributors? We’re willing to pay for the value, so why not just change–?

PIPPIN: One problem with that is then people game the system and make everybody outside contributors even though they’re actual, in-company contributors, which is a problem.

BRAD: But that could be a management nightmare for most organizations, right?

PIPPIN: Oh, I’m sure, but you know people would still do it.

BRAD: Yeah.

PIPPIN: What I would like to see is for it to be similar to Help Scout’s pricing. Help Scout prices you by the user, but only if they’re active. I think Trello does the same thing. We’ll stick with Trello because I know they do that. If you have a user, and you pay for that user because you’re on their gold plan and it’s user based pricing, and that user becomes inactive for a month, they are not charged for that month. They’re only charged if they are active. I’d have no problem with that kind of system.

In order for a user, a collaborator to a private repository, in order for them to affect the billing rate, they have to leave comments, commits, open issues, or something in a time period, so only if they’re active. I’d be completely okay with that because then having a bunch of bystanders sitting there doesn’t hurt me.

BRAD: Yeah.

PIPPIN: But, paying for bystanders, to me, just is very wrong.

BRAD: Let me understand this read only idea. That was one thing you guys mentioned earlier that I hadn’t thought of is that anyone that just has read only access to a private repo wouldn’t be counted as a member of the organization. That would still allow them to submit pull requests because they could clone the repo to their own side and then submit the pull request, right?

PIPPIN: Mm-hmm.

DEVIN: Right.

BRAD: Right, so they just wouldn’t be able to open a branch on, like, the main repo like a member of the organization. I think that–

PIPPIN: It would be just like any other public repository that is–

BRAD: Right.

DEVIN: I think they’d end up losing money, though, because I don’t know how many people have write access to your Easy Digital Downloads, but, for Give, it’s only, I think, two, two people.

BRAD: Oh, really?

PIPPIN: We actually have a lot that have write access.

DEVIN: Oh, really?

BRAD: Oh, so even people within your organization just clone the repo and do PRs that way? Is that what you mean?

DEVIN: Yeah. I like the history of PRs anyways, as well.

BRAD: Well, we do PRs as well, but we all have write access to the main repo, and we open our branches on that main repo just so all the branches are in that one place just in case someone goes on vacation and leaves a branch in their home repo.

PIPPIN: Exactly what we do and why we do it because we had branches get left in the forks, and we had trouble retrieving them.

BRAD: Yeah. I think most organizations probably have it set up that way for that reason, right?

PIPPIN: I want to pose a question to you guys. In some way, GitHub, with these pricing changes, appear to be stifling open source collaboration. At the same time, conversely, they are really encouraging open source collaboration by encourage or discouraging private repositories.

BRAD: Right.

PIPPIN: And encouraging people to make everything public.

DEVIN: When I said that earlier, when I said private repository and open source in the same sentence, it just kind of felt wrong.

BRAD: Yeah.

PIPPIN: Yeah.

BRAD: Yeah.

PIPPIN: What do you think? Does that completely negate all of the negative aspects to it? Should we just say, “Forget it,” and make everything public anyway?

DEVIN: Will it save me the money? You’ve been doing pretty well on Affiliate WP. It’s been public this whole time, right?

PIPPIN: Yeah, since day one.

BRAD: Yeah. I think the problem, though, is that not every product is the same, right? If you’re building a developer tool, GitHub is kind of where they hang out.

DEVIN: Yeah.

PIPPIN: That’s precisely why our software licensing add-on is a private repository because it’s a developer tool.

BRAD: Yeah.

PIPPIN: It’s not that we don’t want developers to have access to it. It’s just that, well, it still needs to be a sustainable business. While it might be perfectly fine to put it on GitHub, I’m a little leery to make it open to anybody because our customer audience is also our developer audience.

DEVIN: For us, I would put everything public if it came down to it. Right now, I don’t think there’d be any business, adverse business effects of it.

BRAD: Right, but who are your customers? Are your customers developers, mainly?

DEVIN: No. No, definitely not.

BRAD: Right.

DEVIN: But, for you, I would more than reconsider that.

BRAD: Yeah. Huh.

PIPPIN: I think what we will probably end up doing is making everything, but a few plugins, public, and then we will probably just kick everybody off, which is the unfortunate thing. Software licensing, for example, we have a lot of WordPress developers that are on there. We have over 50 or 60 people that have access to that plugin in the private repository, and all of them are developers that use it to sell their own plugins, and so we want them in there because we want their feedback, if they submit a pull request to it, et cetera. But, the unfortunate reality is it’s probably not worth $500 a month or $400 or $500 more than we currently pay to have those occasional pieces of feedback for one plugin.

BRAD: Do you guys think that this is kind of unique to the WordPress ecosystem and how businesses are set up? How many other projects out there have the add-on model where they would have private repos of add-ons for this open source product? I’m just trying to think. Most other businesses are SaaS, right? They’re not distributing downloadable software.

DEVIN: Right. Did you guys see any flack outside the WordPress industry given to GitHub besides this?

PIPPIN: I saw a thread on Reddit in the Web Dev subreddit where it was a mix of basically everybody who used GitHub for personal reasons and only had a personal account were thrilled, as they should be. But, everybody who had an organization account, most of them were unhappy, and that was definitely outside of the WordPress world. That’s so far been my perception is anybody who has an organization account is unhappy with it because it’s only organizations that are affected.

DEVIN: It’s interesting that the individuals are because, if they’re successful, they’re going to grow into organizations.

BRAD: Yeah, but no one ever looks that far ahead.

PIPPIN: Well, let’s be honest. A lot of people don’t have foresight into that type of thing. It’s not a criticism of them. It’s jus like, in this moment, I’m thrilled because I pay $10 less per month. Whoo-hoo.

BRAD: Yeah. Well, I saw some comments on Twitter of people celebrating. Then, like an hour later, they’re tweeting, “Oh. Oh, crap.” They’re realizing that it’s great for individuals and then, “Oh, wait, I’m not just an individual any more.”

PIPPIN: That was my first reaction too. I saw it. I read the excerpt of the article. I was like, “Great! This is awesome! Uh-oh.”

BRAD: Just as a comparison, when we were talking about value-based pricing, I just looked up my Slack bill for our company, and we’re a small company. We’ve only got eight active Slack users right now. Well, actually, they billing is for nine users. It’s $640 a year. No, $640 — is that per year?

DEVIN: I hope so.

PIPPIN: I hope so.

BRAD: Oh, okay. It’s not even close to the same thing.

PIPPIN: No, but it is kind of the same problem. It’s the same reason that I don’t pay for Slack. We use a free Slack account for this exact same reason, and it’s because the pricing scheme does not encourage organizations with a large number of outside contributors. If I was to pay for a Slack account right now for our three organizations, it will easily cost $500 or $600 a month, and it’s because we have a lot of outside developers and contributors that we have in our Slack accounts so that we can communicate with them. We’re not talking to them every single day, but it’s a very easy way for us to communicate.

If we were to upgrade to a paid account, we would either have to kick everyone out of our Slack account or bite the bullet and pay $500 or $600 a month. The value between what the free version gives and what the paid version gives is not big enough. There’s not a big enough divide between those to justify it.

BRAD: Right. Okay. It’s pretty much exactly the same problem as what GitHub has just introduced to itself. Yeah. Nice. I feel like two pricing schemes is not — that customers could choose between that makes more sense for their organization is not necessarily — you know, I don’t think that should be written off as better. You know, basically them having two different pricing schemes going forward. I don’t know if that’s even possible, if they’re even considering that option, but I don’t know.

DEVIN: They left themselves some wiggle room, it seems.

BRAD: Yeah. Yeah, I think we have to be loud.

DEVIN: Yeah.

BRAD: If we want even that to be a possibility, we’re going to have to keep complaining.

DEVIN: I saw an interesting Tweet that was like, “This GitHub move is equivalent to moveable types’ move to WordPress as it is GitHub to GitLab now.”

PIPPIN: Absolutely. Yeah.

DEVIN: I don’t know if I said that right, but–

PIPPIN: No. No, I think you nailed it, and it’s actually exactly what I was about to bring up. I just pulled up the WP Tavern article on it, and there’s a bunch of comments on there. I think Jay Trip put it perfectly. I’ve got to see if I can pull up his tweet real quick about it?

DEVIN: Jay Trip? I haven’t heard that before.

PIPPIN: Oh, John James Jacoby, yeah, but he put it pretty nicely.

BRAD: Maybe we should define what GitLab is because I don’t really know what it is, to be honest.

PIPPIN: GitLab is basically a free, self-hosted, open source version of GitHub. It is a project that somebody started to basically mimic GitHub’s functionality, but in a self-hosted environment where you own your code. Your own the repositories. It’s all installed on your own server, but it has a lot of the same functionality.

BRAD: It’s been around a while, new, or what?

DEVIN: It’s pretty good.

PIPPIN: Quite a while, I think. He put it pretty nicely. “Today is for GitLab what 2007 was for WordPress. If code is poetry, GitLab is your library. Own your code like you own your content.”

I really like that sentiment. I believe 2007 was related to the movable type stuff. And so, if you want to have complete control over everything and you really believe in owning your content and stuff, then GitLab is something you should probably consider because we have to remember: Anything we put on GitHub is not ours – GitHub’s. Their ability to change pricing and do anything that they want with it is an example of that.

BRAD: Is that actually true, though, that if you put it on GitHub?

PIPPIN: I’m sure there’s some wiggle room there. I’m sure that wouldn’t stand up in court that GitHub owns everything.

BRAD: I’m pretty sure we still own copyrights and all that stuff.

PIPPIN: But, it’s on their systems. If they wanted to suddenly delete it, they probably have that right.

BRAD: And, there is stuff that is locked in there, right? There is probably some data. I mean you’d probably get it out through the API, but it would be a pretty painful process. You’d have to build a migration tool and who knows what.

I just looked up GitLab, their history, and it started as a little project in 2011 by some developer, I guess. But, the company was incorporated in 2014, so a couple years ago. They went through Y-Combinator, it looks like, and so yeah, they seem pretty legit, right?

PIPPIN: I know a lot of people that use them.

BRAD: I guess what’s concerning to me when people suggest, “Oh, let’s just move to this free alternative, open source project over here,” is that just reminds me of Trac. You know what I mean?

PIPPIN: Yeah.

BRAD: Then you end up in the situation that people are in today where they’re still on Trac, and Trac is not moving forward.

PIPPIN: It’s a problem of: you build a product, so do you build the tools to build your product or do you use the tools that someone else built as their product?

BRAD: Yeah. I’m not sure….

PIPPIN: I’ve always been of the mentality that I don’t want to build what we use to build our products. I want to build our products and nothing else. If the systems that we rely on to build our products, if it has a problem, I don’t necessarily want to be the one that has to fix it. It’s the same reason that we went from a custom bbPress install that we managed and we built for our support system to Help Scout. Help Scout builds the support system and, when it goes down, their team is on top of it.

When our forms install had a problem, we were the only ones that were going to take care of it. And, any time that we spent building that was time not spent building our product. I look at things like GitLab the same way. I think they’re wonderful tools. They’re not something that I personally want to use because of that same reason.

DEVIN: Yeah, and they do have an enterprise edition that’s hosted on their servers, but then what’s the difference between that and GitHub?

PIPPIN: Right.

BRAD: Yeah. I guess that’s the argument though. I think there’s an enterprise edition that you can install, self-install too. Is there? I don’t know what their business model is.

DEVIN: Oh, yeah.

BRAD: Yeah. I think, Pippin, you just summed up my thoughts on that. I think the difference, though, between going with Trac or with GitLab is at least GitLab has a company behind it. They seem to have a sustainable business model that is fostering the development and the pushing forward of their open source project. So, I’m less concerned in this situation than if it’s just an open source project run by volunteers with no corporate — no money behind it because people have to eat, right? Developers have to eat too, and so I feel like those projects that don’t have any corporate backing are more at risk for stagnation. That’s just, I guess, why I shy away from those ones. But, yeah, this one might be a good alternative.

PIPPIN: Yeah. I just discovered a blog post from GitLab on their blog that is a response to the GitHub pricing increase. Definitely worth a read if this is something that interests you, so we’ll make sure to leave that in the show notes. You can find it at GitLab.com and go to their blog. But, I was just skimming over it, and it seems to be a pretty good response. Definitely an interesting subject and, in one way or other, I think we’re going to see some changes in the next 6 to 12 months. I don’t know what those will be. I’m hoping there’s some adjustment for it because there are not very many people that are going to be okay with going from $25 to $500. I saw one. I think Human Made tweeted that their price would go from around $25 or $100 to over $2,000 a month.

BRAD: That’s nuts.

PIPPIN: Right. I think the key detail to remember is with no added value.

BRAD: Right. I think one thing, when people give those numbers, what I would really like to hear is not what your current pricing would be, not what your current pricing is versus the new pricing. What your base pricing is if you have to eliminate all your outside contributors. If you would eliminate all those, what’s your pricing? Then what’s your pricing if you keep them?

That’s the number that’s really having a big impact here. This is the number that’s killing collaboration. We all agree that we don’t mind a bump in the price. It’s just that when the bump in the price is ridiculous, then we have to make sacrifices to get that price down. Yeah.

PIPPIN: Yeah. Devin, do you want to tell everybody real quick where they can find you if they want to get in touch with you, ask you anything about WordImpress or Give or any of your other products or projects?

DEVIN: Sure. My personal website is ImDev.in. You can check out WordImpress.com as well and GiveWP.com.

PIPPIN: All right. Thank you so much coming on, Devin.

DEVIN: Thanks, guys.

BRAD: Talk to you next time.