Hacker News Reader

Comment by thecodrr | Hacker News Reader

These guys also tried to submit PRs on the Notesnook[0] repository. The PRs are really good but there's no way to talk to the actual developer working behind those PRs. They have a single central account named "gitstart" and all PRs that any of their user works on falls under that account. Of course, we couldn't accept PRs from them because they don't follow DCO[1] i.e., DCO requires that the committer MUST NOT be an organization.

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.

[0] https://github.com/streetwriters/notesnook

[1] https://developercertificate.org/

View on HN

> The PRs are really good but there's no way to talk to the actual developer working behind those PRs.

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.

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 don’t think you’re being treated any more unfairly than anyone else trying to break into the US market. It’s simply a case that a decade of experience and being a skilled programmer are not enough to stand out from the crowd.

Depending on your location there may be legal restrictions preventing from US companies hiring you - even through a B2B contract.

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

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.

If you are highly skilled already, it should be very viable to just work with OSS projects directly. For example in Python, the Django & DRF projects are always looking for contributors (though Django can take a long time to land substantial features).

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.

> For big companies you need to drill LeetCode and system design. Perhaps for startups it is not the worst use of your time.

Exactly. Any hiring manager with a brain and not bound my clueless corporate processes would use OSS contributions are a decent signal for proficiency and social skills.

That means nothing in a big corp though. The hiring panel will never accept a candidate that fails the Leetc0d3 test because that means other panels could do the same and then it all falls apart for them. Status quo and all.

To be fair, it’s a hard optimization problem. If you are trying to remove bias from your hiring process then it is difficult to objectively score things like OSS contributions. (I do agree it’s something most bigcorps could do better.)

As a small company you don’t need to try to remove bias with objective metrics (indeed, “culture fit” and “thinks like me” can be good heuristics for building a small tight-knit and high-performing team) but when you hit the company size where you must introduce multiple layers of management, then fully trusting each line manager’s subjective judgements can lead to very disparate quality and other political/organizational issues.

If you are a highly skilled programmer, why not just start contributing to open source repos yourself? You don't need to go through GitStart to get there.

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.

If you're comfortable sharing, could you elaborate on how a transition from unpaid contributions to some kind of paid work arrangement typically happens.

In your experience, is there usually a more or less deterministic path to a stage where the question of starting to get paid usually comes up? Who initiates it?

The result of this discussion may very well be that the company isn't interested in this kind of relationship for any number of good reasons. But what's important, I think, is for a contributor to be able to have the right expectations coming in. As in:

- Should I join on a purely for fun basis and see where it goes from there, keeping in mind things most likely will stay this way going forward.

- Or if everyone is happy with the quality of code, communication, etc across a number of pull requests, then it's definitely OK and expected to bring up the question of payment/employment.

Thank you.

Often if you send 3 large useful PRS to a corporate open source product you will find an email in your inbox asking to connect.

Send a couple more high quality PRs and you can likely leverage that into a job.

So ”3 large useful PRs” have the same expectancy as connecting with a recruiter on LinkedIn ?

Your public contributions are a showcase of your alleged skills, in most cases.

There is no deterministic way to transition from unpaid to paid. It's just one signal among many that a recruiter or company looking for services would look into.

> Of course, we couldn't accept PRs from them because they don't follow DCO[1] i.e., DCO requires that the committer MUST NOT be an organization.

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.

Where does this require that the submitter not be an organization? Even if you're fully committed to that idea, the obvious approach would appear to be:

(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.

That's a weird document. It seems that it actually wants the submitter to certify that either A & B are true, or C is, and that D is acceptable. But it lists them like you must accept all 4, but all A & C can't both be true at the same time.

Yes, it's malformed. There is no expectation that (a) and (c) can be simultaneously satisfied, since they are linked by a chain of "or"s. But it seems clear that the intent of the document is that you're supposed to certify two things:

   I. At least one of (a), (b), (c) is true.

  II. I understand and agree as specified in (d).

In other words, (d) is not parallel to (a), (b), and (c) -- it's a drafting mistake to put it in the same sequence of clauses.

It is on our roadmap to properly integrate DCO on the platform, as its a hard blocker for all repos under the linux foundation. We already add each devs that touches the PR internally as co-author now

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

What's the point of DCO? Really don't understand why you would want to cripple yourself with that.

It's a lot easier to trust an individual than it is to trust an entire organization which is effectively trusting every individual who may have access at that org at any given time.

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.

What do you mean by co-signing? We currently do attribute the work using "Co-authored-by:" in the commit message. I'm not sure if there's any other/better way to do it.

On top of that, we are thinking about developer profile you can share as a part of your resume. I'd love to hear some suggestions on what you think we should include in it.

"Co-authored-by" cannot be validated. Well, no commit can without signing (and there are issues even withthat).

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?

You can't.

I retract my previous statement! If you're already doing the Co-authored-by, that is fantastic, then their names are clickable on GitHub, and the developers themselves will be able to directly interact through their own GitHub accounts if they are @'ed by the customer. This is great. Definitely advertise that aspect.

In general my advice is this is one of those gray area markets where it is extremely easy to exploit workers, so you should do everything humanly possible to make sure that:

a) workers in this program are progressing with the goal being they can eventually "graduate" to the point where a middle-man is not required. This won't be possible across the board but an evil version of this startup would be designed to keep workers in this situation as long as possible, so just don't be that.

b) Allow customers who want to direct hire specific workers to do so seamlessly and don't do hefty referral fees that are enough to stop a lean startup from being able to pull the trigger. I've personally witnessed startups unable to pull the trigger in such situations because they can't afford to "buy the person out" of whatever referral company owns them. Don't be like that. If you absolutely must do a referral fee, structure it so they at least get back the money in credits with your program or something.

c) Treat workers like the assets they are -- each worker that eventually gets a job through your program becomes a marketing asset that will drive referrals from their home country when they eventually find success and tell their friends how they succeeded. Make sure you have created a positive enough experience for them that they will actually recommend you and dear god give them referral fees when they send you someone.

That's my free advice

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!

Reply on news.ycombinator.com