Do you think outsourcing (“gets outsourced anyways”) still happens for most tech teams? IMO, just like you mentioned, teams are so scared of outsourcing that this happens less and less.
I agree that this works for well scoped tickets that only depend on the code and testable on a staging environment. Anything outside of that needs in-house devs (or contractors) to get done.
Currently most of dev bounty platforms do start with OSS, but we only started doing that last year.
Because of that, 90% of users of our commercial usage today is still close-source, and biggest customer base are from heavily regulated industries like insurance, finance, and even commercial banking, with 2 of them having > $15B each under management.
Now, as you pointed out, we had to implement and background checks, audit logs and have direct full-time relationship with devs through our subsidiaries.
But what made the biggest difference was our security tooling like GitSlice, which along with dev environments cuts down majority of risk exposure.
I would be really curious why you think something like this wont work for private repos?
Since you have implemented BG and other controls. My follow up question is are these devs in that case EOR or contractors whose payroll is processed via you. Your org starts to look like deel, remote or midsource.
The whole PR assigning to junior devs feels gimmicky, no?
However, there are two problem statements you are solving. I agree with the first premise, remote junior devs will get better opportunities and confidence when they do this exercise. I think the second part of value generation, I think risk is too high for a closed source org.
We enable EOR + BR + MDM setup on the enterprise plan. Plus, MDM is usually gimmicky given most devs for these clients work in a virtual environment anyways (so the code never leaves their infrastructure).
IMO if we fail as a company, it will be far more likely because of inability to deliver high quality PRs instead of inability to get through compliance.
Most companies hiring remotely don't have if your 1-person company is US-based or not.
The ones that care to hiring within vetted countries for $reasons usually will not accept exceptions. Notable example is GitHub which has a list of countries they hire from (even though they're owned by MSFT and could hire on the Moon if they wanted).
Having a company is mostly for tax purposes. It makes everything easier. I think the hiring company doesn't care if the contract is done with a business or an individual. Both are usually limited liability and offer no advantage in case of contract breaches.
My personal take is that the highest level of trust lies with the in-house team. If thats broken, you need to restructure the team until trust is established again.
I am really skeptical about a service (like pullrequest.com) where external reviewers come in to gate-keep internal PRs. It can work like CI / CD checks (e.g pentesting, SonarCube). But its next to impossible to truly suggest changes that make a difference without knowing the context.
At GitStart, we have tried hard to make sure we are accelerate and empower the in-house teams, instead of shrinking them or trying to replace their need.
We currently attribute commits back to every single dev involved in a PR (including reviewers) as co-authors. We also actively work with our customers to allow devs to mention their contributions in their CV publicly. And you can always reach out to them directly if they have an open position (especially mentioning your experience working with them through GitStart)
What would be an ideal way to attribute the hard work back to the devs in our case?
In the last month, we have rejected quite a few tickets that may have been easily tackled by a senior dev. Including technical documentation for infra, K8S, CLI agents to collect runtime traces, fixing flaky E2E tests and so on.
Also some cultures also show far less care than others (despite feeling the same way)
A lot of my Asian friends do not pro-actively jump into slack to not look stupid, but the moment you get on a pairing call with them the perception changes quickly as they are not as shy in a smaller group.
In this particular case there was technical discovery on a non-trivial approach to patch an npm package (which didn't work out)
But above aside, one can get a lot more milage out of GitStart if small fixes are bundled together. As that means all of them share the cost of QA (across devices), bundled code review and less context switch overhead.
The whole product disenfranchises upcoming junior devs of their potential earnings and credit for their efforts. "I built and shipped product X which generated Y revenue for company Z" read better than "I worked on a series of PRs across many different products with little insight to the product as a whole or much say in the technical direction".
This sort of thing will likely reduce number of devs that move on from junior to senior long term and put people off of joining the industry overall.
To be honest, I didn't until now. The first six comments are automated, and I stopped scrolling fairly quickly. My bad, and I'll quietly be mad at the state of the GitHub PR "discussion" tab that has just too much spam in it.
I'm glad you wrote your last paragraph! I did wonder how much of the credits cost was just overhead as the costs of small/medium/large are fairly close to each other. It makes sense to me.
GitHub PR detail view is a hot mess. The entire page is endlessly long, with very poor signal to noise ratio
We are very tempted to re-build that experience on the dashboard(at-least for our PRs), but I hope someone can launch a simple dashboard a better UX to replace the current PR detail view
I agree that this works for well scoped tickets that only depend on the code and testable on a staging environment. Anything outside of that needs in-house devs (or contractors) to get done.