rich-markdown-editor VS gitlab

Thanks! We forked this version of ProseMirror built by the Outline team which was the closest to what we wanted for our product

https://github.com/outline/rich-markdown-editor

Outline's rich-markdown-editor (https://github.com/outline/rich-markdown-editor) package is pretty nice. I have used it to make some custom MD editor/CMS experiment.

Good eye! This is indeed based on ProseMirror. I didn't create it myself though, I'm using this: https://github.com/outline/rich-markdown-editor

Ah yes, I found the library I was using for the editor (rich-markdown-editor) to insert a lot of \ newlines when they weren't needed. I'll take a look at this sometime!

The outline editor is open source https://github.com/outline/rich-markdown-editor

It runs a mult-tenant SaaS app with very low memory/cpu requirements (https://getoutline.com/)

In case someone from Gitlab is watching: there is a long-standing issue that Gitlab Dependency Proxy does not work with containerd rewriting (https://gitlab.com/gitlab-org/gitlab/-/issues/350485), making it impossible to use as a generic Docker Hub mirror.

To add another link, I think this is the same issue: https://gitlab.com/gitlab-org/gitlab/-/issues/421396

Spoken like someone who has not tried what you are describing. There are two moving parts to your response: a locally hosted runner awaits jobs from GitLab itself, which doesn't help running _locally_, and the other part is that --back when it existed! -- trying $(gitlab-runner exec) was not a full fledged implementation of the GitLab CI concepts, making it the uncanny valley of "run something locally."

However, as of v16 there is no more exec https://gitlab.com/gitlab-org/gitlab/-/issues/385235 which I guess is good and bad. Good in that it not longer sets improper expectations that it could have plausibly done anything, and bad in that now it joins GitHub Actions in not having any _local_ test strategy aside from "boot up gitlab/gitlab-ce && echo good luck"

https://gitlab.com/gitlab-org/gitlab/-/compare/v17.1.6-ee......

The merge commit with calling out environment stop actions:

https://gitlab.com/gitlab-org/gitlab/-/issues/327121 is the first one, and I'm having trouble locating up the second (possibly due to the search pollution from the first one) but there are a bunch of "Exiftool has been updated to version [0-9.]+ in order to mitigate security issues" style lines in their security releases feed so it's possible they were bitten by upstream Exiftool CVEs

Anyway, turns out that shelling out to an external binary fed with bytes from the Internet is good fun

I'm not sure I personally agree with this, and I'm not 100% sure the developer community at-large does either...

Let's take a few examples, which I've shared elsewhere in similar discussions:

- GitLab: Open Source or Open Core? Most would say Open Source, but (I assume) you would argue Open Core [0].

- Plausible: Open Source or Open Core? They say Open Source, but it's actually Open Core [1].

- Cal.com: Open Source or Open Core? They say Open Source, but once again, Open Core [2].

- Posthog: Open Source or Open Core? They say Open Source, still Open Core [3].

- Sidekiq: Open Source or Open Core? Once again: Open Core [4].

Yet, every dev I know would consider these projects Open Source. So there's a disconnect somewhere.

Under this mindset, very few open source startups are actually open source, yet everybody says they are?

I'm not trying to argue either way; I'm trying to point out a disconnect here.

[0]: https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/LICENS...

[1]: https://github.com/plausible/analytics/blob/2dd2f058d1dcae6f...

[2]: https://github.com/calcom/cal.com/blob/main/packages/feature...

[3]: https://github.com/PostHog/posthog/blob/master/ee/LICENSE

[4]: https://github.com/sidekiq/sidekiq/blob/main/COMM-LICENSE.tx...

The article is singling out GitHub in the title and for most of the article, only in the very last line they declare that this behavior is a common design flow and not limited to GitHub:

> Finally, while our research focused on GitHub, it’s important to note that some of these issues exist on other version control system products

For example, Gitlab only recently solved this: https://gitlab.com/gitlab-org/gitlab/-/issues/408137

Also, I don't appreciate the fearmongering. Multiple times they repeated statements like how you can "Access Private Repo Data" when it's a rather special case related to forks. They clarify that later but I found these statements repeated in that fashion, whether intentionally or not, very cheap. Especially for a tech blog, where the material itself is good and could stand on its own.