How do we collaborate on PRO features if they're closed-source?

[tabacitu]

Background: Backpack v5 has the features split into two projects: CRUD and PRO. The most complex ones are in the closed-source repo backpack/pro.

Problem: Since it's closed-source:

• we can't accept issues directly on that repo (they are added in backpack/crud)
• we can't accept PRs to that repo
• people can't fork that repo and maintain their own fork
• because people can't collaborate on the code the same way they're used to, it feels "forced" or "gated" or "hidden"

We'd LOVE TO invite people who have access to use backpack/pro to also collaborate on backpack/pro. We'd love to. But we can't easily do that, because on Github every collaborator costs. Out of a 69 EUR license, 35-42 EUR would go to Github. That's more than 50%, so it's impossible to do that for everybody who purchases.

But we do want to offer the same collaboration experience for PRO features, as we do for FREE features. So let's brainstorm. What are our options? Here's what I thought of:

Option 1. Invite collaborators to the Github repo, when they offer to submit a PR. This is what we'll be doing, until we find a better long-term solution. So if anybody wants to submit a PR to backpack/pro or backpack/devtools - especially people with a history of submitting PRs, please let us know in that issue/comment and we'll invite you as a collaborator to the repo. But I do NOT think this is a good long-term solution:

• for collaborators - it still doesn't feel the same, you have to ask for temporary access;
• for users - it doesn't invite you to browse the code, see how it works and become a collaborator;
• for users - talks about PRO features might seem to happen "behind the scenes"; (they don't, we don't talk in those repos much, we keep all conversations in public)
• for maintainers - it takes time and effort to manage collaborator access; time that could be spent building features;
• for maintainers - we have to answer difficult questions like "this person hasn't contributed in x months/years, should we still pay for their collaborator access?";
• for maintainers - the costs will prevent us from doing this for all collaborators too (~250 contributors * 42 EUR ~= 10.000 EUR/year)... that's a lot for a small company like Backpack;

Option 2. Raise the price to 99 EUR, to include a big part of the for Github collaborator access. I don't like this. I want the cheapest option to be cheap. 69 EUR seems a lot cheaper than 99 EUR.

Option 3. Offer Github access as a paid addon - extra 40 EUR. I don't like this, when someone wants Github access it's because they want to help with a PR or something. How can we ask them money to do so?

Option 4. Run a self-hosted GitLab instance, and have backpack/pro, backpack/devtools and all other closed-source repos there. Upon purchase, that email gets access to the repos they bought. When their update expires, Gitlab access is removed.

PROs:

• pretty egalitarian - everybody who pays or collaborates gets collaboration access;
• pretty similar to Github (from our research);
• talks are divided into two platforms - Github and Gitlab, with the talks on Gitlab taking priority;
• once we spend the time to set it up, integrate it with backpackforlaravel.com and re-do the Github actions to the Gitlab system... it won't cost us a lot of money every month/year;

CONs:

• talks are divided into two platforms - Github and Gitlab...
• similar to Github... but NOT the same... so we all have to get accustomed to that too;
• Github actions won't work on Gitlab, so we have to re-do them;

---

This is all I got right now. Anybody else have any ideas? Thoughts on the options above? Feel free to disagree with me, this is how we learn.

Cheers!

[shirshak55]

Option 4 looks like a better choice in long run.

[guleswine]

It seems to me that option 4 is the only one possible in a closed source environment where no additional investment is required from all parties, another service is not a problem.(at my work we already use gitlab )

The only negative is that it will be a closed place, which will reduce the number of developers interested in the project, and what happens in the backpack will no longer be visible publicly, but apparently there is no other way out when the project has a closed part. (and this is most likely related to all options, this is my personal opinion from the outside :))

P.S.
perhaps my concern is exaggerated, since the open part on the github leaves room for adding your own cool ideas to the project

[tabacitu]

Right. Valid concern. I guess we can keep all the talks on Github (here) and use GitLab only for PRs. That could work too.