My preliminary open source project search, in the style of reality TV show The Bachelor.

Also: Maintainer POV, Github Numbering Quirks, and weekly contributions

theQuestion = “To Fork, or Not to Fork”

If you’ve never seen The Bachelor:

• First, you probably aren’t missing out on much. (I haven’t either)
• Second, it is essentially a televised elimination-style competition drama show about several women vying to be the final choice as romantic interest for a bachelor.
• Third, why am I mentioning a reality TV show in a blog about Open Source Development? For parody reasons, of course!

Introducing The Contributor, where one contributor (me) gets to know several Open Source projects to find the perfect match. Projects that stay in consideration get a fork instead of a rose , and the final project standing might just get (a contribution) proposed!

Before I list the projects and which candidates made it through the round, I want to note my own biases. Essentially all of the projects I looked at had codebases hosted on Github, because it is the software forge I’m most familiar with. I feel as though I should make an effort to at least get slightly more acquainted with other sites, mainly Gitlab. Also, though I am probably in the minority in this, lack of an explicit CODE OF CONDUCT document is not a deal breaker for me when considering a project. From my limited experience it seems smaller projects more often don’t have them. If I don’t see any glaring issues when browsing a project’s activity and discussions in issues/requests, I’m willing to take the benefit of the doubt and assume the community follows a general golden rule standard. I want to believe the open source community as a whole is more good than not. Having the document is of course an important plus though, and very good practice in general.

Round 1: Welcomeness

• p5.js (LGPL v2.1): Artsy and Educational JS Library

  • This is a very good candidate with an extremely welcoming community! There are several projects that fall under the “p5” umbrella: core p5.js, the p5.js website, a p5 web editor, and a p5 audio library. The main repo contains a CODE OF CONDUCT that implicitly extends across all the p5 projects. The project has been made to be as inviting as possible for new contributors, and the main repo even contains a first-timers-only issue label (though there are currently no open issues there. It’s the thought that counts!). I used this library a lot in the beginning of my CS journey, and it allowed me to dive in to JavaScript by building cool interactive games. p5.js hits all the key points and more with a bit of nostalgia, so I would just need to find an issue that fits my abilities and scope.

• Electron (MIT): Web Dev, but for Desktop Apps

  • This project is extremely active, with thousands of issues, recent commits, and a good first issue label that actually contains a few issues. All the essential documents are present, with extensive development docs and helpful links. It also contains a good mix of languages for my personal preferences - about half C++ followed by mostly TypeScript/Javascript. Definitely a fork.

• The Fuck (MIT): Dirty Name, Clean Terminal Commands

  • Excuse the bad language. This is a rad command line tool that helps correct typos or incorrect console commands. It is fairly active, with basic, yet still inviting documents. According to Github, it is also entirely written in Python. Honestly, the worst thing about this project is probably the fact that it isn’t licensed under the WTFPL. (I found out about this fun license after the fact, and was ready to suggest a license change myself before checking the issues and learning that the maintainer has chosen to stick with the MIT license due to preference :/ ) Since the project is relatively small I can see myself trying to add or fix a bug in a use case directly relevant to me. Would fork.

• Hugo (APACHE v2.0): Static Site Generator Built in Go

  • This project looks very inviting and beginner friendly, and most of the necessary docs are present (there isn’t a CODE OF CONDUCT). The only real barrier to contributing is my experience level with programming in Go: zero. Am I willing/able to try to learn a new language within a semester just to possibly make a contribution?

• Manim (MIT*): Math Animation Engine

  • This animation library was created by math Youtuber 3b1b, originally for his videos. (If you’ve never heard of him you should check out his channel, it’s interesting stuff.) As such, it is pretty small, but decently active despite this. From a glance in the issue discussions, the community seems very helpful. The README does mention a dire need for tests and/or documentation …
    *One specific directory (from_3b1b) is separately licensed and exclusively permissable to use for this project, but the rest is under a normal MIT license.

• Leaflet (BSD 2-Clause): JS Map Library

  • Built using OpenStreetMap, this project is also fairly beginner friendly and contains a good first issue issue label. The CONTRIBUTING doc mentions that they have a specific goal of keeping the library fast and simple, so I’d have to keep that in mind when thinking about contributing. Leaflet gets a fork.

• React-Leaflet (MIT): Leaflet, but in React

  • This is much smaller than Leaflet and slightly less active, but follows the same ideals and seems just as open to contributions.

• Memegen (MIT): Meme Generator API

  • A project focused on memes? Sign me up. There is a fair amount of activity, a good-first-issue issue label exists, and the essential documents are straightforward. They mention a need for more developer installation docs.

• Origami.js (GPL v3.0): HTML5 Canvas Library

  • The name of this project is slightly misleading, as it has little to do with the paper folding art. Origami.js is a library built to make using the Canvas API for drawing graphics easier. The CONTRIBUTING document is basic, but very polite and encouraging. However, there has been very slow/almost no activity in the past 6 months, so it probably won’t be practical in the timeframe of a semester. This project does not get a fork.

• Albert (GPL v3.0?) : Desktop Keyboard Launcher

  • This project also seems to have little recent activity. The last commit was over a year ago. The installation docs don’t have any macOS instructions though, so I could possibly contribute by making a guide, but for the moment: no fork. Besides the lack of activity, another more important issue is the licensing on the project. The website homepage claims Albert is “GPL-licensed, 100% free and open source”. However, the repository does not actually contain any LICENSE/COPYING file in the root directory. An issue regarding this was opened last year, but is still open. I searched the term ‘license’ in the repository and discovered a single file with the GNU GPL v3 in the header. A little more digging revealed that previously all of the files contained this header, but a LICENSE file was never added when all the headers got removed. This pull request explains the situation and attempted to resolve it, but was closed by the author after 2 months and no comments. Albert has some copyright baggage to figure out, and I can’t have that bringing down a free contributor like me.

Overall, I’d be willing to contribute to most of the projects listed here, so as I continue to search and evaluate I’ll be narrowing down acceptible criteria for a project choice.

And now, back to the regularly scheduled program…

PR From the Other Side

This week I began editing some of my peers blogs, mostly making small grammar and wording changes, and also fixing an incorrectly formatted markdown link. On the flip side, I also merged my first PR (pull-request) as a maintainer, which was an interesting experience. The activity gives some insight into what it’s like at the other end of our contributions and pull requests, having to make sure outside changes are useful, don’t break anything, and merge without issues. It’s an entirely different frame of mind.

#1, #2, create issue; #3, #4 commit more

Through looking at several pull requests and issues in peer blogs, I discovered a quirk of Github: issues and pull requests share the same numbering sequence. Before taking this course I never took more than a cursory glance at the pull request or issue tabs, and in the first few weeks we only looked at relatively large, more established project repositories with hundreds or thousands of issues/PRs, so I never would have noticed this before. When an issue is first created, it is identified by #1, and following issues increment from there, but when a pull request is made it picks up from where issues left off, and vice versa.

Of course one of my first thoughts was that this means certain PR/issue numbers will simply not exist in a project. That possibility combined with the knowledge that Github uses the url schemes <user>/<repo>/pull/<pullnumber> and <user>/<repo>/issues/<issuenumber> for pull request and issue urls respectively led to a slightly cooler discovery: Github automatically redirects the pull/issue text in the url based on the # being passed. For instance, in dmallia17’s blog repository, there is an issue labeled #1 and a pull request labeled #2. If I visit dmallia17-weekly/pull/1, the site will automatically change the url to dmallia17-weekly/issues/1. This only reinforces the idea that Github developers made a deliberate choice to make them share the same pool of IDs. The redirect behavior probably doesn’t carry through in other places such as the API though, but I haven’t looked into that (yet). I attempted to look into why they don’t have numbering independent of each other, but only found a github community forum post with some thoughts and no official answer. It does sort of make sense after some thought, since PRs and issues are very closely related in a project. I think the reasoning could also involve the fact that PR/issue numbers preceded by a ‘#’ can be used to mention any issue or PR from any other issue or PR, and if they had independent numbering there would be conflicts (i.e are you mentioning issue #2 or PR #2?).

While checking the uniqueness of this behavior I found that Gitlab actually uses an independent numbering system, with issues preceded by a ‘#’ and merge requests (their term for a pull request) preceded by a ‘!’. The more you know.

Though this tidbit will most likely never come up in practice while using Github and getting involved with issues and pull requests and the like, it was noteworthy to me and may even possibly come in handy in some niche edge use cases.

Back to the Map

I added several restaurants in the neighborhood around the Hunter dorms on OpenStreetMap. I’ve noticed that many of the food places in the area south of Murray Hill are missing on the map, so I might plan an excursion into ‘Little India’ in the coming weeks.

Email-SchmEmail

I have been working on a contribution to the openstreetmap website repo mentioned last week, but my last comment has not been responded to for several days :(. Besides that I’ve had a solid back and forth with maintainer feedback involving discussions about email regexes in ruby. There appear to only be two maintainers, so I’ll just have to wait to see when they’ll comment again. Perhaps they may even merge the pull request! (Wishful thinking).

---

Remember to tune in next time for another episode of The Contributor to see which projects can make it to the installation round!

Credits:

Executive Producer
boubascript

Co-Executive Producer
boubascript

Produced by
boubascript

Co-Producer
boubascript

Consulting Producer
stewartweiss

Starring
boubascript as Himself

Guest Starring
3b1b

Writer
boubascript