hzia

Congrats team! Graphite was basically what GitHub should have been but never was

Huge fans of their work @ GitStart!

Most heavy users of python notebooks (including us) have a hate love relationship with it, especially when you add it into git.

Honestly this is worth alone for the fact that there isn't random JSON blobs coming in PR diffs.

I wish more people tried it out instead of complaining about the blog post text.

This is very exciting! Existing data will become a lot more valuable and it brings it one step closer to how we learn as humans!

The downside is that this is going to be extremely expensive, so the data set to conduct RL will need to be curated.

I agree on the Bell Labs analogy

Most browsers have consolidated over time because we are constantly updating web standards and bar for security is so high. On top of that everything has to be insanely backward compatible

WebGPU is a good example. Implementing that securely in a nightmare

Majority of revenue base lives on iOS globally (due to being a monopoly in the US)

That's why Apple has higher profits than all other mobile operators combined!

I think you are drastically overestimating the revenue gain from ad blockers

But I agree that default search with being Google must have heavily blocked competition.

Comparing how much they pay Mozilla and Apple to maintain search, it would be reasonable to estimate Chrome’s implementation to save them $1b a year

But I highly doubt they make any back given > 1k people work on it

That’s revenue not profits. Majority goes to app devs.

Profits are all that matter

I think most people do not understand that Google funnels a lot of their profits to make Chrome and Android into OSS.

Youtube may be the only viable company that can come out of Google. Rest will either have to charge a lot of money or die.

And we will be left with an even more profitable ad giant, that sends back all profits to it's share holders.

That sounds really low. Do you mind sharing where you rent your racks from?

Thank you so much for that!! I wondered about this as well. Love how above and beyond you guys are going to support other OSS implementations <3

How do you sign multiple devs on a commit though? Would it be a joint PGP key signed by all keys of all devs that helped with the PR?

GitStart only takes care of well scoped tickets in backlog and finishes them at the PR stage. There is so much more to do including:

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.

Your advice is spot on, and why we wanted to build a better than the current status quo!

a) we already have a sizeable alumni who have gone through GitStart over time, with many still in touch. We are in works to bring them all together in discord

b) there is no current restriction or even referral feel for both devs and companies to work with each other. The only thing we ask is for devs to either be full time on the platform or work with them directly and pause GitStart

c) good people recommend more good people! And we have a program where as alumni they get free credits for their own companies (over 5 have launched their company and used those free credits)

We currently do not have a referral program for alumni to recommend devs (it is there for currently active devs) but that’s a great idea to roll out!

I appreciate the candid honestly! Even though we are aiming to become a career accelerator for junior devs, not everyone is going to graduate right away. For some, just a few months of experience is enough but for others it can take years.

But at the end of the day, success for both devs and engineering teams (aka clients) on our platform depend on the PRs shipped. Which is why we focus all of our energy on the PR lifecycle. All key metrics driven from PRs (review cycles, time to merge, merge rate and so on).

By keeping laser focus to complete a PR, both parties win. Which is why we optimize for that first, and on top of that build further ways for junior devs to grow and teams to accelerate their velocity.

So if we need to add more human management to ship better PRs we do that. But later if solving a client need can enable them to write better tickets (which will facilitate better PRs) then we shift our focus to that.

We already have email+password+verification_link combo for client dashboard, and we are soon bringing it to our developer dashboard soon! (along with a brand new dev focused website)

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.

How was your experience recruiting and working with dev teams based out of China? And how do you enforce foreign contracts from aboard (or draft local ones with a sub within China?)

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.

Internally we are expanding ways in which we draft multiple PRs initially when new devs onboard and send the one with the best peer review approval

We could infant send all the draft PRs upstream. And as a senior dev upstream, you review and merge the approach that works best

It would be offensive for most in-house teams to try to give our duplicated work, but universities and bootcamps get students to learn by doing the same thing in parallel anyways

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.

Quite a few are due to priority changes over time. We are thinking to automatically close PRs when there is no activity for > 14 days.

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?

Unless there is a strong regulation like HIPAA, I have seen setting up a US based company (through Stripe Atlas) take care of most legal woes.

But ultimately it depends on the motivation of the company itself, and they use all sorts of excuses to not work with non-US staff

Agreed ... the service itself has to hold ground on its own.

Thats why on our landing page, the focus is on the service itself with some mission interleaved. Would you reckon it's the right balance?

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 love this! We can make it even easier to ask for emoji reaction to the PR description instead of a comment to make it 2 click to take action

And build an experience that guides them through the PR instead of getting distracted by nit picks. I we can only go so much with GitHub UX (bar chrome extension), so we may just have to rebuild the entire thing in our dashboard.

Currently we include a loom video on every PR (if its a frontend PR) along with a unique link to our dashboard to review / approve credit budgets. But we should double down to give a potentially better PR review experience and take over the experience in the long term

And to keep memory usage under control, we restart the non-deterministic service every 2 days because we were too scrapy to clean up memory after using it.

Jim said we will add more bugs fixing it so we believe him.

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?

I see more interest on this than I expected!

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)

Good point!

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.