Hacker News Reader

Comment by luhn | Hacker News Reader

This is going to be great for open source—Being able to get a fully-configured dev environment at a click of a button greatly lowers the barrier to entry. I've had a few small OS contributions where the time to set up the environment was more than the time I spent programming!

I could also see this being popular with engineering teams. No futzing with the new hire's computer, just have them open a web browser and they can dive right in!

View on HN

I'm not sure if this is really true. Why would you want to become a contributor to an OSS project if you can't bother to get it working on your machine? You actually learn quite a bit about the project by going through its dependency hell.

Idk, I feel like we've been trained to believe this is necessary. Why you should need to know more about a dependency than its documented API? This sort of reminds me of Americans believing their current healthcare situation is the only way to do it even though it's awful.

Don't get me wrong - I don't think that you should go through it every time. Also, I'm not sure anyone reads the documented API of a dependency until some unexpected behaviour is happening. My basic point is that the dependency hell is not the biggest barrier for an open source contribution. In fact, mixing both problems is a bit strange to me - codespaces is not going to magically solve the dependency hell - it's just going to shift it to some other part of the configuration. The best way to start contributing to an OSS project is really be to have a mentor in project who could guide you through it during your first contribution. Personally, I'm willing to fight the machine for a couple of hours/days to get something to compile -- however, it's hard to justify reading code for weeks in the hope I can tackle an open issue.

Sometimes setup on different platforms is different in very subtle and hard to debug ways, and for smaller OSS projects that haven't yet been tested on different platforms, it may be very hard to figure that out. Now you can develop even on a chromebook (without the terminal access) without having to deal with any of that.

The only time I could see myself using this is in the following scenario;

1. Browsing repos.

2. See a quick fix I could make (like a typo)

3. Open up the code space view, make the change, add and commit it.

For my daily needs I would never replace an online IDE with my local IDE. I see no value in doing that. My concern would be for when github has a service outage. I am without my IDE until they resolve the issue? With a local IDE I can just continue to work on my branch and push it when GH comes back online.

> The only time I could see myself using this is in the following scenario

You can already do this. There's an edit button when you view any file and a streamlined process for turning your change into a PR. I don't think Codespaces will make this any faster. Maybe you can fix slightly less trivial things due to the IDE support but on the level you described no new capabilities are added.

I think with the same editor experience as I use on my own machine, I can fix substantially more complicated issues, with significantly less effort.

I contribute to various OSS (and private) projects all time just by using the GitHub code editor and catching errors or regressions if any in the CI. Having a fully fledged dev environment is even better.

This is pretty cool. Can you share a bit more about your experience? I would like to be able to help out this way.

Basically it's just the same as whipping out a simple text editor in hurry; if I need to modify multiple files, I just do multiple commits (do a change -> commit -> jump to my branch/fork -> do the rest of the changes one by one) as GitHub doesn't support editing multiple files for a single commit and then I wait for the CI results. If something goes awry I'll probably clone the repo at that point.

Most of the time when I contribute to a GH project it works like this: I use the product, discover a bug, search on their GH, don’t find it, file a new bug report, clone the source fix the bug, submit PR, never commit to the same project again.

The threshold for doing that sort of minor work can be lowered a lot by this.

I'd like to be able to contribute to Firefox or Brave, but there's no way I'm going through with the setup.

If I could just do some small stuff, maybe write some unit tests, that would be fine.

If going through the setup is hell, what makes you believe that it'll be easier to contribute after you get it for free? I still believe the best way is for OSS projects to ask contributors to do some mentoring...

> what makes you believe that it'll be easier to contribute after you get it [setup] for free

I'm flabbergasted. Like.. I don't even know where to start. You've been through an on-boarding process before right? Have you led one? Haven't you ever watched a junior dev get dragged through all sorts of arbitrary "don't breathe on it" setups just so they can start making tiny isolated bug fixes?

And even then, you're just following instructions where even most high level developers don't even know why their project is set up the way it is.

We've worked on very, very, very different projects your and I.

I don't understand what your comment have to do with contributing to OSS. Anyway, I don't really believe that codespaces or any out of the box tool is going to be a magical solution for junior devs not be dragged in those kind of setups in the projects that you're referring to.

> magical solution for junior devs not be dragged in those kind of setups in the projects that you're referring to

That's exactly what this is. The setup is part of a clonable environment. So for large scale compiled projects, you wouldn't have to:

1. Download the massive thing 2. Get it to compile 3. Potentially not have to compile many files that already have their `*.o` (or equivalent) file in the environment.

It could be like just walking up to some other developers fully functioning station, and getting started.

Most developers are pissed at programming on the cloud and want to do core development locally on their laptops, if you will force them to cloud edits that good luck getting developers to work with you.

From my experience (in the UK) companies either don't care about your environment assuming you set it up, or they just give you a preconfigured laptop (or workstation)

I've spent the last two weeks working on provisioning scripts to make that possible for enterprise products. It's hell.

Yes, and ( Sadly ) No. I have seen quite a few open source project that refuse to host on Github due to its lock in, proprietary nature.

Personally I have no problem with Github, as its advantage far outweigh its disadvantage.

Reply on news.ycombinator.com