It dependencies

2023-11-18T22:38:17Z ago

Solid episode! I was just thinking the other day—on the the topic of maintaining projects—is the platforms for contributing to OSS are lacking now. Github being a huge provider in all of that, is not a great user experience if you want to make a change for a bug you noticed but not become a lifetime project contributor. It feels more like actual work rather than enjoyment of being involved in open-source ecosystem and interacting with other devs/languages/etc. In some ways, I feel like it’s creating a generation of devs who don’t really get to enjoy making software for the sake of making software/experiential learning and the platforms turn it into “Hot or Not” with all of our code.

2023-11-22T13:04:59Z ago

I agree that submitting a fix upstream often feels like a chore, but I hadn’t considered it was potentially GitHub’s UX that was the major contributing factor to that.

I figured it was just the necessarily complex trappings of the open source process and was/is amazed that we can get it done at all.

Think about it: utter strangers, all over the world, with completely different contexts, submitting code to a common codebase. Kinda crazy it all works out when it does…

2023-11-22T14:09:54Z ago

For what it’s worth, my experience with open source prior to GitHub was pretty bleak. Memories include:

Using an open source library I got from sourceforge or something, but from which I couldn’t discern a web site, contact info, mailing list, version control (where trunk or a current release was all that was hosted) or anything else. The only projects I ever figured any of this out for were ones where I literally knew a guy who knew a guy in real life that I could ask who would then connect me to someone who knew where all the unrelated bits and bobs were
Mailing list software I barely understood to try to explain issues to an undifferentiated soup of subscribers (maintainers, users, trolls) that would oscillate between ignoring me and berating me
An expectation patches being sent by e-mail to be hand-merged by maintainers, but no standard diffing/patching tool, resulting in spending more time getting nitpicked about the formatting of the diff before anyone would even consider the merit of the contents

By centralizing all of these concerns within a year or two of launch while rallying around a competent DVCS tool that could actually handle branching without effectively cp -r‘ing and reuploading the entire tree, GitHub made discovery and collaboration possible at all, and for that I am so overwhelmingly grateful. I don’t doubt there are all kinds of UX improvements to be had and I definitely don’t doubt that many people’s experience trying to break in is still mostly bad, but it’s so night-and-day better than how things used to be that taking the angle that “GitHub is bad actually”, doesn’t really resonate with me.

I do hope that if there is a UX solution to the underlying social problems you describe, that someone with fresh eyes finds them—but I’m always dubious of people assuming that a tool is going to resolve what are fundamentally human issues. GitHub was a technical solution to technical problems that were so dramatic that they exacerbated underlying social issues, which is why it felt like a “social coding” revolution and a solution to a human problem, but in hindsight I see it as crystalizing and exposing various social problems in a more-or-less essential form, and every tool I’ve seen to try to iterate further just abstracts and obfuscates those social problems as opposed to facilitating their resolution.

2023-11-22T23:44:25Z ago

I don’t disagree with any of that. Especially memories of the sourceforge days. I remember when Twitter first came out I primarily used it as point 2 for dev projects. The good old days, ha! Github certainly improved all of that, which I’m not knocking in any way nor do I consider it bad.

However I think that the “social coding platform” has become more of an idea within the business than the business being a social coding platform. Maybe even a bit more social than coding, given project discovery is based on likes and follows than code/language similarity and relevance. I think the current product is excellent for large OSS projects like Rails or Grafana where there are many maintainers and may have a more structured release plan, using all the tools available for managing a project—like work. For a solo-maintainer, especially if your project gets suddenly popular (every React UI framework ever), it becomes more time intensive for the maintainer and the contributors when the tool is team focused (this is truly on the homepage).

As a contributor I see a few issues:

You have to fork and check out the whole project to make a small fix. That project now lives forever in my github account since it takes 6 steps to remove it.
You have no visibility into what anyone else may be doing without scouring every issue, which may lead to people thinking “somebody else is probably doing that”.*

For both, given the maintainer is also a contributor:

If you have multiple PRs, you may merge one that outdates another, now the contributor has to fix and the maintainer has to review again. I see those get orphaned a lot and it’s somewhat of a rigmarole to copy/fix them yourself.
My active contributions are not really at the forefront when I log in, it’s just the feed of what other people are doing. Also it’s all in the browser interface. Not in GH desktop or the cli or a VS Code plugin.

The reason I think some of that can be mitigated with UX/tooling is because you can have most of this with just git itself in a branch strategy vs forking. Don’t get me wrong, I love the way forking/PRs work but you do need some internal help via extra tooling to regain some of the stock git functions. You can kind of see it in the network graph in the UI but I think that’s it. The PR stream as well. It’s presented as a chronological list but that’s really not what’s happening when you intend to merge things. The entire “tree” of git is converted to flat lists in every aspect of the platform, meaning you manually organize a lot of things as the maintainer. That certainly helped in the early days given the learning curve of git, but I think people learning engineering now are more conceptually aware than when it was like SVN to git overnight. So while I don’t know if any of that truly resolves what was discussed here and in the pod, I do think that we’re due for some improvement in how we’re able to maintain and contribute to OSS. Not sure if that comes from GitHub or not.

*Random thought, using a bit of AI to show where I can contribute to projects I follow. Wouldn’t that be two birds one stone? AI finds what it thinks are code improvements, human devs either agree and make improvement PR or disagree and ignore it, thus training the AI on what improvements look like either way.