We recruit devs who want to grow from remote countries, to work full-time on these tickets and review each other’s PRs. For tech teams it’s pay as you go, and they only pay if they merge the PRs (we pay our devs a base regardless). GitStart is very personal to me because I struggled myself to start my career as a junior dev. Being born in Pakistan made it super hard to find my first remote job. Things changed with Google Summer of Code, which was the first time I got paid to contribute to a large production codebase.
When I became a staff engineer, I started mentoring junior devs on their solo projects. I then realized what they really needed was production code experience, so I started sending them tickets from my backlog to grow them through code reviews. I also paid them for it. They learned a lot and I got a lot done, which started GitStart.
That’s why, in the description above, we say “devs who want to grow”. This is key to what we do—we are not just a body shop or middleman, and we don’t charge by the hour. We provide useful mentorship to junior devs. We want to be a meaningful part of their career path.
Our thesis (to use that slightly pretentious word) is that the economics work better this way as well. There is a lot of junior dev talent in these countries whose potential will bever be realized by hourly piecework. What’s needed are longer term relationships and work engagements, over the course of which a junior dev can learn and grow on a large production codebase. Much of this has to do with learning the culture of effective tech teams.
On the other side, effective tech teams don’t want hourly piecework either. Clients tell us they love having developers dedicated to their project, becoming more familiar with the code over time. This is the way for value to be maximized on both sides.
A number of commercial open source repos already use us, so you can check out some of the PRs created by GitStart here:
Cal.com: https://github.com/calcom/cal.com/pulls?q=is%3Apr+author%3Ag...
SourceGraph: https://github.com/sourcegraph/sourcegraph/pulls?q=is%3Apr+a...
StoryBooks: https://github.com/storybookjs/storybook/pulls?q=is%3Apr+aut...
Strapi: https://github.com/strapi/strapi/pulls?q=is%3Aclosed+is%3Apr...
Supabase: https://github.com/supabase/supabase/pulls?q=is%3Apr+author%...
Twenty: https://github.com/twentyhq/twenty/pulls?q=is%3Apr+author%3A...
Our main technical challenge has been securing code sharing. One solution was building GitSlice, which enables creating sub-repos that sync with the upstream repo. When GitStart devs create PRs on the platform, GitSlice syncs them upstream while pulling back CI/CD checks and review comments. This enables our devs to contribute with limited codebase access.
To prevent slices from breaking, we verify they run within a docker container, which also enables us to build review environments. Fun fact: we managed to support native iOS and Android codebases by building and running them on appetize.io instead of docker.
There have been countless attempts at this space so we would love to hear your feedback on how we approached this problem or your past experiences working with junior devs in this way. We look forward to a good conversation!
I talked to them about this and they said they'd work on it etc. etc. Not sure if anything has changed in that regard or not.
I'd really like an avenue to get into the US market as a remote worker, but am being unfairly treated by this job market. It is a pity as I am both a highly skilled programmer and have nearly a decade of experience. I'd consider this service if it could serve to showcase my skills, but if I am not going to get any credit for doing the work personally, there doesn't seem to be much point to it.
Many companies, including my own and the commercial open source companies mentioned in this post, consider open source contributions a major factor in hiring remote talent.
Depending on your location there may be legal restrictions preventing from US companies hiring you - even through a B2B contract.
In my experience as a hiring manager it was quite rare to see lots of OSS work in candidates’ GitHub accounts, but I’d absolutely prioritize those that had good work in OSS. (Also worth emphasizing that technical design, collaboration, and documentation are important and underrated, and can also be showcased in an OSS project. If you can demonstrate good communications in an async OSS environment, that would probably reflect well on your ability to contribute as a remote employee.)
All that said I’m not sure that OSS is the best resume builder. For big companies you need to drill LeetCode and system design. Perhaps for startups it is not the worst use of your time.
What would be an ideal way to attribute the hard work back to the devs in our case?
I read the certificate. It isn't long:
Developer Certificate of Origin
Version 1.1
Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
(1) GitStart releases their patch under the open source license of the project's choice.
(2) An employee of GitStart submits it, in their official capacity, to the project, asserting under clause (b) that the contribution is based on (consists entirely of) previous work that is covered under an appropriate license.
The problem lies in the definition that “committer most NOT be an organization” which would require us to do a full review of our legal contract with devs so that this condition is upheld properly
We often think of orgs as these big trusty things but honestly they are just groups of individuals, and it's harder to trust N individuals than it is to trust one individual, especially when the N is opaque and unbounded.
What they should do is co-sign the PRs/commits so it's the worker's personal account + the GitStart account. Then the workers are actually building a git repertoire for themselves which puts them a step closer to independence. That might go too much against the exploiting cheap labor theme that seems to be lurking in the dark here though. That said, I would love to be pleasantly surprised if GitStart is OK with co-signing commits alongside accounts directly in the control of their workers. Would definitely be based, doubt it will happen.
At a lot of jobs I've dealt with using contractors, there was an internal concern that people external "didn't care" enough. How do you plan on addressing this concern?
It's a system that will depend a lot on trust, and it may be difficult to build that with companies whos DNA does not lend them to trust outsiders AT ALL let alone let them come in and muck with production level code (letting juniors do it!)
I'm playing devils advocate, like I said I think your idea is cool and worth exploring. Not enough companies invest in juniors to grow them into their full potential, and I commend you for this effort. Good luck.
That’s correct. Either you are a full time employee, or you get second-class culture even if you are part of internal slack. It’s very hard to get external contractors to be excited when they dont get the swag / on-sites and share the culture.
Which is why we want to have devs belong first class citizens in the GitStart Community, and join all hands / game nights and learn from others. And our integrations push through PRs and all the updates to engineering teams.
It’s not the lack of swag or on-sites. Companies usually outsource to cut costs, so there’s your problem. Also, I’m not convinced there’s correlation between being “excited” about a company and producing good quality results.
While GitStart pays their developers, that alone could encourage better habits, I fear it could also enable this chasing reward mentality harder, setting the juniors up for failure, as well as frustrating the customer with having to deny and review multiple low-quailty PRs.
How is this avoided? This seems heavily at risk to cause more headache than help.
To prevent “Hacktoberfest” style PRs, we have a strong peer review system internally along with QA. Which is the reason why most of the above open source projects have found it a lot easier to merge GitStart PRs than the PRs by juniors posted directly
I do wonder though how we this problem can be solved for all junior devs contributing to OSS
From my experience hiring, both full-time employees and contractors can not care; it felt more about the individual's character than their employment status.
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.
the developers are typically folks who wouldn’t be able to get a remote job otherwise due to universities not being globally recognized or english is not super fluent. many developers grow a lot during their time at gitstart and eventually move on to getting jobs at places like Google, Amazon too. they support any developer to grow (there’s a team dedicated to figure out growth paths for each developer on the platform)
disclaimer: i used to work at gitstart
Worth acknowledging that GitStart has, at least in the past, submitted PRs to open source projects unsolicited in an attempt to bolster their reputation.
We found their PRs to be of extremely rough quality - exactly what you would expect from junior offshore developers - and it took up a non-trivial amount of our time to deal with the contributions and get them into a state where they could be merged. We would also often find 10+ email addresses associated with a single one-line change commit, which I found quite odd.
While I/we encourage contributions from developers of all levels, it felt super iffy that we were investing in coaching the junior developers of the YC/VC-backed startup, only for them to use us for cred.
In the end I believe we blocked GitStart from our repo.
I remember your case personally and reached out to you over email to apologize at that time last year. If there is anything else did wrong, please let us know
To be charitable: could have been that the commit started off big and complex, getting modified and reviewed by several people over time... before one person finally figured out how to simplify it down to one line — and so then they rebase-squashed it down to just that line, rather than polluting your commit history with all the intervening nonsense.
It is sad that developers from global south usually have to perform at a much higher level than their peers at the north, just because unfounded prejudices.
I’ve seen great developers from basically everywhere, but the vast majority is garbage (at least at first).
This sounds odd. Why just from "remote countries"?
Is it because they can be paid less than in not so remote countries?
Are you going to ensure that if someone from the UK hires such a service, the worker performing it will be paid at least the UK minimum wage for the time spent?
I have a feeling this is just another way to get cheap labour.
You make it sound like it’s a Bad Thing (TM). The apprentices that sign up for this gain real world experience that’s hard to come by locally and get paid for it.
This kind of extended apprenticeship is valuable as they can go on to land remote jobs that pay them better than their local market.
Perhaps they could have worded that more clearly as: “we recruit devs . . . from low-income countries with English as their official language”
This is how they are able to make the economics work.
EDIT:
https://www.pullrequest.com/ is a comparable service (where you involve “outsiders” with your codebase) except they use senior devs rather than junior devs. Of course senior devs are more farther along in their careers so it is clear you are paying for their experience.
It has a great potential for widening the social divide. Here in the UK it is illegal to hire an apprentice without at least paying them a minimum wage. The reason is that before the change, the apprenticeships were snapped up by people from wealthy background who could afford to work for "experience" or "exposure". This created a bubble, where at certain jobs you wouldn't see anyone from disadvantaged background working there, because those people had to take on jobs that weren't aligned with their interests, simply because they were poor and couldn't afford an apprenticeship. Now, the minimum wage thing is still not ideal, because in certain areas that's not enough, especially where you have a large family to support, but it is better than nothing.
A UK based, official Google Cloud partner was offering him £2.50 per hour gross for a DevOps position. Yes, £2.50.
I didn't believe it until he forwarded me their official offer letter.
When seeing $10/credit, I thought a PR this small would be just one or two credits. I'd totally pay $150 to fix 10-15 such small bugs, but only one? Am I missing something?
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.
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.
You can see that this PR took a while to get merged (~2 months) with multiple iterations as shown here https://reviews.gitsense.com/insights/github?bq=8218%2Bpull-...
Full Disclosure: This is my tool
When your employer onboards new hires, do they have a commit merged into main in their first 90 minutes with the company?
Software development is an expensive business, and some companies are used to paying this much and more. The no-fix-no-fee pricing model would also command a premium over hourly work.
The reason we have not done that is because we get all devs to commit full time on the platform, and thats a deal breaker for senior devs. Part time doesnt work well for juniors to reasonable grow on the platform, but I can defn see that working for seniors.
Curiously, how you do see your normal day look like if you could something like GitStart on the side as a part time senior?
Also, I go through periods where I only want to work 8-16 hours a week, but even most contract work I find is full time.
So really for me this would allow for more liquidity in my contract work.
I would probably not do it for the money (cant imagine it would pay 150USD/h), but mostly to keep exposure to new codebases, ideas, challenges.
I think you should target this offering at people that already do contracting at first, though I think I would miss the opportunity to talk with the team. It is hard to make big changes (expected of senior folks) without design meetings and coordination.
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.
Hola at me if you are interested! (email in bio)
They had their Show HN about 4 months ago: Show HN: Algora – Paid open-source contributions https://news.ycombinator.com/item?id=35412226
- This does not work beyond OSS projects. This is literally a compliance leaders nightmare. I just don't know who is touching the code, how and where ahead of time, no background checks etc.
- Secondly, this feels like a nice way to "growth hack" you Github stars and fake some metrics for VCs. Your pitchdeck can 100s of contributors and 1000s of stars without really creating much value.
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?
- They might be running shadow IT
- Security and compliance is not their priority.
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.
I have yet to have a super positive experience with the quality of work of offshore contractors either internally hired or via an external consulting company.
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.
On this page. The error is coming from your GraphQL backend:
{ "errors": [ { "message": "has invalid format", "path": [ "createDeveloperProfile" ] } ], "data": { "createDeveloperProfile": null } }
Thanks for the report. Turns out it was one of the Falsehoods Programmers Believe About Names[0] we'll deploy the fix in a moment.
[0] https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-...
I love working with earlier career engineers but their code isn't known to always be very high quality. How does that work on GitStart?
We are not fully there yet, but you can see from the Open Source PRs above that its good enough that this can make an in-house team more productive than the default.
Biggest part that makes it work are enabling multiple devs to review each other, solid QA and dev environments to reduce hand-holding and a community to grow and learn from.
Larger corps like Google already have this infra setup, but most teams cant afford to build it internally.
It got merged so clearly the devs find value in the work but I wouldn't call that production ready.
We first got the more experienced junior on the repo review others. Later on, we started to enable multiple devs to work on the same PR initially, review each other and best one sent back
And with GitSlice, we have been able to take very large codebases and slice it to a smaller repo that is much easier for juniors to work on.
So now we get teachers and seniors to train juniors, but they are not in the loop of the PR execution anymore.
Is GitStart a significant pivot from what you started with?
The harder part was getting the system to work (aka ship solid PRs while delivering a good growth path for juniors).
Most of the time was spent building a ton of in-house tech (especially around security, dev environments, review environments and so on)
We are now in a better position to automatically onboarding engineering teams (and later this year do the same for devs to sign up and start to ship PRs on the platform)
I wonder if companies will double down on full remote or this will revert back slightly.
In general, jr devs are net-negative. (If they're not, they're not junior! promote them!). They are an investment, they are learning and growing. It will take a senior longer to review, mentor, and coach them to a PR that the senior could've gone straight to that same PR. The whole point is that eventually you've grown another senior dev who will return big multiples on their compensation.
This sounds like you're just going to be spending sr dev time reviewing and rejecting, to have de minimis backlog items (there's a reason they're in the backlog and not prioritized) fixed, and you're not even growing a senior dev, which is the whole point.
Plus, IME most companies carry so much cultural context that being exposed to it for exactly 1 ticket + not having inside people to ask questions means this will be an uphill battle.
With GitStart, we take everything else away entirely (dev envs, preview links, mentorship, trainings etc), with strong processes to make sure PRs are heavily reviewed internally with solid QA before its pushed upstream. I think this drastically reduces cost of working with juniors to the point that its “profitable”
Right now it’s not for everyone, especially for companies where there not enough motivation internally to craft good tickets or having enough backlog thats critical enough to make use of GitStart.
Now everything aside, we actually have seen cases where devs internally grow within, apply to our customers and become full time hires! We dont bind our devs at all to join our customers directly and instead celebrate it when it happens!
"Plus, IME most companies carry so much cultural context that being exposed to it for exactly 1 ticket + not having inside people to ask questions means this will be an uphill battle."
I'm curious as to how you make this work when I'd imagine even a simple ticket for anywhere I've worked would go something like this: "first learn our monorepo, then learn how all the internal testing tooling works, and oops your PR is going to touch our in-house/NIH'd migration system. Also you can't just rename this db column, let me explain our db replication strategy (which you can't touch or observe since no way would a non-employee have any of our AWS access, even for dev). oh and Jim (haha good ole jim, he wrote like 40% of the code and then got fired after 2 years because he told the CTO to go fuck himself) wrote that code in a rush in the before times so it's creaky, try not to ever touch or look at it, so work around it in the app code even if you might otherwise want to change it" and so on and so on.
(I also find learning all this stuff - the NIH systems, the stack, who the Jim is this time around and what code he wrote, etc - is like 85% of the part of spinning up at a new company and it takes like 6 months of fireside campfire stories to pick up enough of the lore)
It sounds like a shop like this would basically mean devs are eternally in that "doesn't know about Jim's code yet" stage.
There is nothing stopping devs from getting recruited directly, in-fact we want that to happen! Its a major success story for us when devs get hired, ideally back to our customers :)
As a result, the end team that uses GitStart has full ownership of all code that gets merged.
However you can assign future bug fixes and maintenance work back to GitStart.
i would think gitstart as an extension to engineers themselves instead of working in silo
disclaimer: i used to work at gitstart
* "Do work, but get paid only if we use it" feels potentially exploitative. You do mention a "base pay" rate but I wonder how it compares to the "merged PR" rate?
* Code quality and adherence to internal code standards is challenging for external contributions. Open source projects, of course, are already used to this, so it's not surprising to see that's where the bulk of your current customer base lives; it's more difficult to see how this would work with other types of organization -- I'd be concerned that I'm spending more time in code review and such than I'd gain in contributed lines of code.
* The whole setup seems to fit in an uncomfortable middle ground between just hiring an offshore developer directly or through a traditional outsourcing firm, on the one hand; and hourly piecework on the other. The only advantage I see to this sort of arrangement on the hiring end compared to regular old long-contract outsourcing is that I don't have to pay for work I don't end up using, but that circles me right back to the "exploitative" part.
90% of compensation for devs is base and does not depend on the “merge PR” rate (which is in-fact 95%)
> * Code quality and adherence to internal code standards is challenging for external contributions
> The whole setup seems to fit in an uncomfortable middle ground
Majority of our customers are in-fact private and not OSS. We can unfortunately only share the latter. But it is targeted towards engineering teams that have already started to invest into DevEx and building tooling to make contribution easier We do help to set that up if customers sign up on the Team or Enterprise plan as a first sprint to add all these guardrails in place.
I agree that junior devs today are heavily exploited by existing freelance and outsourcing platforms where it's a race to the cheapest contractor in the market. For teams who want to freelance, we are not a good fit (and most likely more expensive). Where we do shine is an in-house team that does not have the bandwidth to hand-hold each external contractor one by one to become productive. And with that focus, our devs get to enjoy a fixed base stipend, career ladder internally to grow and successfully joining our customers and / or larger corps like Meta, Google and so on
88 PRs created: https://reviews.gitsense.com/insights/github?p=days-open&q=a...
70 merged: https://reviews.gitsense.com/insights/github?p=days-open&q=a...
7 rejected: (closed/not merged) https://reviews.gitsense.com/insights/github?p=days-open&q=a...
Interesting take away is, the merge rate is quite high, but since we can assume these PRs were created for a reason, can we also say 7 not being merged is also bad?
Full Disclosure: This is my tool
I think basic NLP on the PR decision may be able to automatically differentiate them
https://reviews.gitsense.com/insights/github?p=days-open&q=a...
Yeah, I don’t care.
I don’t mean to be harsh, but if I have to justify spending my company’s money on this, this is definitely not something I’m going to say. This isn’t charity, and I’m looking for quality code.
Which is why we actively monitor review cycles as our biggest metric internally to make sure quality is solid across all active repos.
From the comments I read I can tell the receiving devs can easily become grumpy if things are not as they want to the semi-colon.
A few ideas to solve that problem.
1. Have an internal team of experienced devs who make CRs and onboard the team of juniors on a new projects. From my experience, after a couple mistakes or misfit code, juniors adapt themselves, learn and end-up doing perfectly well.
2. When you submit a PR, submit a process with it (in a readme of some sort) with instructions on how the receiving devs should proceed with the PR. If they are not happy with it, maybe they can just say "not happy with it" and you take on yourself to figure out why. That sort of instructions. The last thing you want is them complaining they spend more time on it than simply coding it.
Im pretty sure the management of the human interface here is key because the only way this can work is if you've got off-the-charts feedbacks. You need processes for that (you probably do already).
And also agree about engineering teams being super nitpicky. We recently rolled out a change to suggest tickets to add linting / formatting tools automatically based on nitpick comments https://gitstart.com/changelog/ticket-suggestions-private-be...
However, I am very curious about the approach of pushing out process with every PR. Would that come as form of a PR description?
Yes. Always the same though (maybe with some variants you write over time). I think the best might be to guide the receiving party so they act exactly like you want.
Example:
"Hello nice to meet you. We are a bunch of junior devs learning to make production code. We'd appreciate if you'd read our PR. However, if at first glance it doesnt look at all like something you'd merge, please simply send us a "nope" and we'll figure out why ourselves with the help of our mentors. Our goal is for you not to spend time on totally off-road PRs.
However if the PR is interesting to you, please proceed like you always do.
You can always reach us via [some form url that's automatically generated for that PR]"
Something like that that someone who can write and think has writen.
Take control at every step to prevent the receiving party to roam freely with the PR so to speak (unless it's decently good), because they might gonna go left and right - and south otherwise. They'll attack you on superficial thing. Make them a smooth funnel so they dont have to talk to nobody to move forward.
That's what came to mind.
P.s. or send them a url they follow entirely.
1. Read the PR in 15 min and come back here
2. How do you like it at first glance? A) very much, it's merged already, B) it's okay but I have feedbacks, C) not at all what we need sorry.
Etc.
I have been working with overseas dev teams for the past 3 years, particularly in China.
If you are interested in getting developers based in China, you can reach out to me and we can have a chat.
We already have customers and a subsidiary based out of Hong Kong, and it will not be a stretch to scale those customers further from devs within China.
- HQ in China (Singapore office where I work, as a subsidiary), the contractors sign contract with a contracting firm and the contracting firm sign the contract with HQ (This is called 人力外包 "manpower outsourcing")
- HQ in China, HQ set up subsidiary in China for managing contractors, the contractors sign contract with subsidiary directly and are de facto employees of HQ except there is no official contract between them (This is called 内部/子公司外包 "internal/subsidiary outsourcing")
- HQ in Singapore, set up subsidiary in China (need to have someone with Chinese citizenship to make it smooth), contractors sign contract with Chinese subsidiary.
- Freelance arrangement where the contractor sign a freelance arrangement with company directly. The jurisdiction and validity of the contract may be quite blur so it relies on good working relationship and trust.
In my opinion, there is a large pool of talented developers based in China and the main obstacles for them to get a remote job are international bank account, language barrier and the great firewall.
If you can overcome the 3 issues then you have access to some really good developers across all levels.
For example, in my first job, I was tasked with greying out a button after it had been clicked. Trivial and generic task. But I was paired with a brand new senior to do the work and we spent a day trying to find the correct button (being new and wanting to seem useful, we didn't want to ask).
It got a lot better with covid which started the wave of remote work and teams started to care about writing tickets for the first time.
Currently we solve it with ticket templates, but we are now doubling down on using AI to help craft and improve ticketing writing. It’s still under private beta, but will be live for everyone soon https://gitstart.com/changelog/tickets-by-chat
Do you mean your team? Because this would be an absolutely ludicrous thing to state generally.
> using AI to help craft and improve ticketing writing.
Right so speaking of AI, how do you plan to keep up with github copilot and how can customers be sure that you're not just using copilot under the hood?
Essentially it allows us to give standardise pricing for similar PRs regardless of time spent on them.
Would it be more useful if we launch a calculator where you can input those variables and get back a credit estimate?
1) Code quality is good, I would compare it to a very good junior engineer (I suspect some senior engineers are reviewing the code before shipping it!). We are reviewing all PRs and it usually takes 1 or 2 round of feedbacks before merge.
2) Gitstart developers are very reactive on pull-requests, their response time is not a bottleneck
3) You will need to be very accurate about your features. I think Gitstart direclty makes sense for open-source projects as this is part of the culture to discuss everything on issues, to share resources (figmas, specs, technical vision). If your company already has a culture of documenting most of the knowledge async, this should be a good fit.
You are spot on that GitStart works really well for teams that have a culture or a strong intention of doing that
But I also feel there is a little bit of a pandora’s box here.
The model you’re creating here is more structured ‘gig economy’ path for software dev. Sure, you’ve got things like UpWork, and other freelance products, but the purchasers (e.g., business) are effectively taking a risky bet on the work which can tamper commitment to purchasing work that way.
But with ‘no merge, no fee’ could create a very strange dynamic where companies will opportunistically throw work over the wall and create bounty-like dynamics. I don’t know if this is particularly bad for the purchaser, but for the seller that could lead to some challenges overtime (race to the bottom etc)
If it is abused we would take action to intervene but hasn’t happened yet. When it does happen (< 5%), it’s really good learning feedback for devs
But would you reckon there is another way to solve the power imbalance problem?
We have been able to eliminate a lot of un-usable PRs by having a very strong internal peer review and QA process. So PRs almost certainly works, and code review goes through at-least 2 separate reviewers
TBH, I think adding teachers that grow devs entirely through reviews is a great idea. We currently do give internal training and guidelines for reviewing PRs, but havnt gone that far yet.
> One solution was building GitSlice, which enables creating sub-repos that sync with the upstream repo. When GitStart devs create PRs on the platform, GitSlice syncs them upstream while pulling back CI/CD checks and review comments. This enables our devs to contribute with limited codebase access.
Is this an internal tool or something you also make (or plan to make) available? We have this problem too at Ritza (a technical writing agency), where often our customers have a mono-repo with a docs/ subfolder that we need access too. Currently we solve this with some custom bash scripts and cron to sync just a subfolder to an internal copy, but is far from perfect and still involves some manual cherry-picking.
We go much further than CopyBara by syncing CI / CD pipelines, syncing review comments and so on.
We are considering launching GitSlice as product on its own. If you are interested, email me and I can keep you updated when its ready to test (hamza [at] gitstart [dot] com)
And there's no way to edit the "cover letter" and they don't even ask for resume.
A simple "You are on the waiting list!" page is shown.
Unfortunately the developer waiting list is quite long so it may be a while before we get back to you. But we are scaling quickly to fix that later this year.
> Neo led the round alongside Microsoft CTO Kevin Scott, Google VP Parisa Tabriz, Andela founder Iyinola Aboyeji, Uber CEO Dara Khosrowshahi, Instagram VP Maria Zhang, Circle CTO Li Fan and VP Yongsheng Wu, Robinhood VP Surabhi Gupta, Quora CEO Adam D’Angelo, GitHub technical advisor Omoju Miller, Gigster founder Debo Olaosebikan, BloomTech founder Austen Allred, Replit CEO Amjad Masad, Airbnb co-founder Nate Blecharczyk, Mike Schroepfer and others.
I wouldn't exactly call this list unremarkable
We have automated on-boarding flow only for JS / TS, but we in-fact support 15 tech stacks including React Native, .Net, Native Mobile & Django
Mobile is our largest tech stack after JS / TS because we were able to build review environment for mobile apps that make it drastically easier for junior devs to review and QA their PR before its pushed upstream without having the actual native device.
I can see image on the left, but the form on the right is offscreen and I think you disabled scrolling so there is no way to get to it.
I had to look at this page on the desktop to learn about that form.
For now, it's best to sign up from a desktop, as the onboarding flow requires connecting GitHub and specifying repos, so this is not very convenient from mobile right now.
technical architecture, API design, breaking down large projects, infrastructure and so on.
All of the above require senior in-house talent. So we want to become the best place for juniors to grow and enable them to join companies to lead the above initiatives.
I do not see a way where we will reduce the need for senior positions.
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.
(Note: I was not asked to post this)
I think the quality of the PRs was fine, I cannot say much about the business model / pricing since we got them for free (out of nowhere - they just started making PRs - much appreciated!)
I suppose that the need for this comes out of the fact that.. we've written a ton of code that needs to be maintained at this point. It's not interesting work, but it's busy work that's still important.
BTW, I could write code, so your page "You're on the waiting list!" will show approximate time.
I could understand, if you don't want to show number of people in wait list, but simple algorithm could forecast and show approx days to wait.
Thank you!
eventually you will have devs gaming the system by working on multiple tasks from multiple outsourcers (like multi-apping for food delivery)
then the quality of the work declines. rejection rate increases. then the base salary will have to go down or become entirely task based.