A Slint fanboy from Berlin.

  • 0 Posts
  • 18 Comments
Joined 1 year ago
cake
Cake day: June 12th, 2023

help-circle

  • Github login does not help much… devs are on github, not on random forgjo instances. That’s where they see your project. Github is also where they put their fork of your project when they play with it. They will write comments using github markdown and won’t care whether that renders correctly or not in your forge.

    And it is where they will report issues and open a PR. It is annoying, but it is how it is. When you ask them to open the PR elsewhere they complain sinde they need to set up an account there and copy ssh key and similar things. You need a very dedicated contributor to go through with all that… especially if it is just a few lines of drive-by fixes.







  • It’s just a git repo, so it does not replace a forge. A forge provides a lot of services around the repo and makes the project discoverable for potential users. None of that is covered by this thing.

    I frankly see little value wrapping a decentralized version control system into layers of cryptography that hides where the data is actually stored (and how long it is going to be stored). Just mirror the repo a couple of times and you have pretty good protection against the code going offline again and you are done. No cryptography needed, and you get a lot of extras, too.

    If you do not like github: Use other forges. Self-host something, go to Codeberg or sourcehut, use something other than git like pijul or fossil, or whatever tickles your fancy. Unfortunately you will miss out on a lot of potential contributors and users there :-(


  • GPL effects “derived works”. So if your code is derived from proprietary code, you can not use GPL, as you would need to re-license the proprietary code and you can’t do that (assuming you do not hold the copyright for the proprietary code). LGPL and permissive licenses are probably fine though.

    Now what exactly is a “derived work”? That is unfortunate up to interpretation and different organizations draw the line in slightly different places. We’d need people to go to court to get that line nailed down more firmly.


  • Then how do you not see the point of a distributed sourceforge?

    But this is no forge, it is just a git repo.

    Again, have you even opened the webpage?

    Yeap, I even put a repo into it. That’s why I am so certain that it is useless.

    Hosting a git repo is not a problem. Having an discoverable forge is. And this does not help with that in any way.

    So github is not a problem?

    Something can not be a solution independent of whether or not something else is another problem or not.

    And regarding crypto, show me where in the code it forces you to use crypto. Show me the rad command that inhibits you from doing a normal git operation by bringing up crypto.

    There is lots of needless crypto(graphy) going on all over the place. It is entirely useless for code hosting in a git repo.


  • No, I would prefer a world where not everything is concentrated on github, but that is the world we have to work with:-)

    But how does this address any of the problems you brought up?

    Do you think a project will be more discoverable when you say: “Clone foo/bar from github” or when you say “install this strange crypto-BS, then clone rad:xyhdhsjsjshhhfuejthhh just like you normally would”?

    Apart from discoverability you get a known workflow for contributors, a CI and a bug tracker. Coincidently those make it hard for projects to switch away from github… how does this address any of that? “Use this workflow, which is even wierder than any of the other github alternatives!” and “just set up a server yourself”?

    Sorry, this is just yet another crypto-bro solution in search of a problem. Technically interesting, I’m give you that, but useless.



  • I mean that the company pays someone (like an existing employee) to maintain their internal fork and contribute patches back upstream.

    Oh, most companies will pay someone to maintain an internal fork, but hardly any will contribute back. Sometimes that’s due to lazyness, sometimes it is the idea that nobody will care for the company internal stuff, but most of the time it is outright forbidden to share internal IP even when that comes in the form of patches to open source code.

    In my experience it is safe to just ignore that case and not care about corporate convenience when starting any open source project.



  • You make it sound as if corporations actually contribute a lot to open source projects they use. That is not the case in 99.9% of all cases where corporations decide to use some open source project.

    If you are lucky as an open source maintainer you get a few patches from devs using their private email addresses to sneak the contribution around the legal department, but even that is rare. What you will see is random requests from company users to provide an SBOM for the entire project right now or bug reports asking to fix something right now.

    So I seriously doubt you loose out when using AGPL or GPL.


  • supply chain attacks are a serious problem that needs addressing.

    Last I checked: I am not a supplier. So I will not invest effort to secure some supply chain for people that I do not have any obligations to: The license clearly states “no warranty” for a reason. I do those projects for fun, not to bother me with security stuff, notifications about security problems some automatic thing “found” that do not really effect my code and bogus merge requests to upgrade dependencies for no reason… this are all cool things if you are a supplier, do not get me wrong, but I am not. No, I will not invest hours of my free time to sign binaries nobody uses either or to fill out security surveys for badges I can display on github.

    If you want me to act like a supplier: Pay me like all the other suppliers you have. I doubt there is any interest to do so for the projects I have on my private github :-)

    For your own projects, it might be worth considering a move away from GitHub. (I’ve been thinking about it since Microsoft bought them.) Codeberg looks like a good alternative.

    That also has associated costs: Your project gets instantly much less visible, so you need to keep a mirror on github for visibility. Unfortunately that also means that you will also get interactions on github, so you will need to log in occasionally to not make people think the project is dead.