• 1 Post
  • 34 Comments
Joined 11 months ago
cake
Cake day: July 14th, 2024

help-circle

  • Why Not Use…?

    I am aware that there are many other git “forge” platforms available. Gitea, Codeberg, and Forgejo all come to mind. Those platforms are great as well. If you prefer those options instead of SourceHut that’s fine! Switching to any of those would still be a massive improvement over GitHub.

    Unfortunately, I find the need to have an account in order to contribute to projects a deal breaker. It causes too much friction for no real gain. Email based workflows will always reign supreme. It’s the OG of code contributions.

    Ive been using codeberg(a public forgejo) and it felt more familiar coming from github/gitlab. Sourcehut wasn’t bad, but it did feel quite a bit different and i admittedly didn’t get too far past that. I do like the idea of contributing without an account though. i know that it’s a git feature to create a patch file but having a forge support it is neat.

    Semi related, I do look forward to federation of forgejo which i think helps the “needing an account” somewhat. I think it’s less unreasonable to expect someone to have an account on -any federated forge- than to have an account at the specific forge my project is on.

    Good article though. It did help make sourcehut make more sense than the first time i looked at it



  • Did you read the article? The author shares their perspective.

    For me, Git is quite powerful on its own with version control, diffs, branches, merging, etc. Forges just add a UI for some of these things, and add an issue tracker/ discussion/etc. Forges also add a more modem ui for repo access though git does have its own webserver you can use. I use git without a forge for a number of my personal projects that I’m not sharing with others or not yet sharing


    1. Site wasn’t properly reflexive for mobile
    2. If this is a portfolio then i would remove a lot of stuff like “watch list” and “current obsession”. The focus should be on your work and future projects
    3. Notes are ok for a start but can be improved. I think a “posts” or “blog” would be better section title, and the content should try to teach something you’ve learned rather than be the notes you took for a subject. The difference is that teaching reinforces your understanding of the topic. So pick something smaller from those topics and teach it. I wouldn’t redo your current notes necessarily, but going forward i would pick a more focused topic and teach.
    4. i would then move the “blog” or “posts” to your front page to show the most recent content and then link to /posts where the rest of it can be found. Or highlight projects on front page instead depending on what you want focus to be.
    5. move your front page content to a more “resume” section that includes a section for the tools you know. And still think about the length/space of this page. Like a printed resume, too long is bad. So make sure it outlines things nicely

    Overall if it was just a personal site id say its ok. But as a portfolio site you have some work to make it align with your goals. Good luck!


  • The archinstaller script is pretty good if you’re just needing a basic setup. Ive been really happy with a btrfs partion from the recommended disk layout, then using btrfs snapshots + grub bootloader to load from snapshots. You can also create a hook on pacman so that you create a snapshot when you upgrade packages.

    Since you didn’t mention your experience, id recommend looking at the various desktop environments so you know which one to pick during install. You can ofc change later.

    And read the arch docs. They are very good and have a lot of time invested into them. If you find you don’t have the patience to read them then you’re probably going to want to look at a different OS. Good luck!


  • Just some general advice:

    • get regular users. Contributors are going to be a subset of users as another commentor mentioned.
    • make sure to have a CONTRIBUTING.md and that it is clear/ easy to follow. Some projects will link to a separate wiki from the .md which is fine. But make sure your “first time contributor” instructions are easy to follow to set up whatever dev environment needed. The less clear the documentation then the more motivated the contributors will need to be.
    • if you haven’t already, make issues with feature requests that you are wanting to add. Include enough details that someone other than you will understand your requirements.
    • consider a label you use to signify “great issue for a first time contribution”. These should be relatively simple fixes or simple features but give time for someone else to try them instead of completing it right away. Make sure to reference this label in your contribution documentation as a great starting point. If you’re able to get someone to do a simple fix then they will have set up the dev environment and may do other future issues.
    • advertise that you’re looking for contributors. Point out your docs, first time contributor label, and any specific features you want/need help with.










  • The difference is that commercialization is inherent with a free (libre) open source license. Whereas going against the intent, but still legally gray area, is imo malicious compliance because it circumvents what the license was intended to solve in the first place.

    But that’s all i really care to add to this convo, since my initial comment my intent was just to say that the AGPLv3 license does not stop corporations from getting free stuff and being able to charge for it-- especially documentation. Have a good one


  • No. I said even if they don’t maliciously comply with the license [by making the open sourced code unusable without the backend code or some other means outside of scope of this conversation] then they can charge for it.

    The malicous part is in brackets in the above paragraph. The license is an OSI approved license that allows commercialization, it would be stupid for me to call that malicious.




  • AGPL is the most restrictive OSI approved license (of the commonly used ones), but it is still a free (libre) open source license. My understanding is just that the AGPL believes in the end-users rights to access to the open source needs to be maintained and therefore places some burden to make the source available if it it’s being run on a server.

    In general, companies run away from anything AGPL, however, some companies will get creative with it and make their source available but in a way that is useless without the backend. And even if they don’t maliciously comply with the license, they can still charge for their services.

    As far as documentation goes, you could license documentation under AGPL, and people could still charge for it. It would just need to be kept available for end-users which i don’t think is really a barrier to use for documentation.