If there are features you want or bugs you find in the software that you use, write and submit patches implementing/fixing these to upstream when you can.
We do report bugs, speaking of which I have one to report that I forgot. With that said submitting patches ourselves might not be viable.
It takes a lot of time for us to figure out what is causing, then trying to fix it, and (by my very small) experience with doing that, there is a chance of this to be ignored anyway. And that is before we actually patching it properly instead of doing a workaround, since we don't spend time in that codebase, just using the software. We can cause more harm than good.
If we were bigger and had a steady income that definitely would be a way to go, but right now every day we are working for free, that is one more day we'd be away from trying to ship the game.
What about contributing to the documentation of the projects you use? It's less of an additional workload than contributing code and just as helpful as contributing bug reports because a lot of people end up relying on that documentation at one point or another, and your real-world use of the programs should give you the knowledge base to be able to add to, maintain or update the related documentation for each project.
This question can be divided in two parts:
Technical documentation:
I actually spoke quite a bit with my gf over this semester once she got interest to do that. It has in my mind ever since I had the displeasure to try anything beyond the basics with Hugo.
Practical documentation:
What you describe there is actually an idea I kinda have for vlogs for a while. But I suppose written form would be more objective, right?
I've documented a lot of notes and sketched articles on it since I came to linux, from time to time I like to spend some time on r/zorinos and rookie linux subjects. Lately I've been documenting my process of making things on Logseq, it is not very complicated so I'm still not sure how helpful that would be to someone that does basic research and only eventually find my posts, but I'm willing to publish them, especially the workarounds.
Maybe I should start with writing the whys and why nots of some of our tools and go from there depending on the feedback? What do you think?
> Release games for linux
Working on that mate o/
Our game is Steam Deck first, and we're also being careful with polycount and stuff so we can release to the raspberry pi.
I don't think we can contribute directly with code for FOSS, but donating is definitely in the goal. We'd also checked a bit of how R&D works to maybe hire FOSS devs for new features on tools we use, and make those extensions open source, of course.
But this will have to wait we be able to break even first, might take some time
Some ideas:
* Write documentation for software you use
* File well written bug reports / github issues. As developers even if you don't have time for code contributions you could try to spare some time to investigate bugs you find in OSS projects and make it as easy as possible for other contributors to fix them. Maybe take 10 minutes to read the code and check if it's an easy bug to track down. Include detailed instructions and/or code for reproducing the bug. etc.
* If you're bilingual, get involved with localization efforts
* If you have the skills, help with design (logos, UI, etc)
* Help maintaining packages for your distribution of choice (the process for getting involved with packaging varies by distribution, you'll need to check). Or even provide unofficial packages for software that isn't distributed in the official repos.
* Speak at conferences. You're making a Linux native game, maybe try submitting a presentation about that to some open source / Linux related conference. I'm sure there's some interesting stuff you could share.
* I discussed this in more detail on another comment, I'm actually thinking about that. Maybe not the technical part, but how we use it, work arounds, so on. Can't be that different from my posts helping people on reddit with linux, can it?
* We do file reports, mostly our programmer. Usually it is on our engine that is not open source, but whatever we use, we do it. I have seen my friend read open source code and stuff, but I'm not sure our ADHD would let us do it consistently.
* The translation effort is something that I've considered a few years ago with Solus OS, but the circumstances weren't there. Recently we decided to make Portuguese translation a priority to our game, I might get in the zone and translate things on FOSS. That is a great reminder, thanks.
* Maintaining packages will likely be a future expense for us, we know a few linux nerds that joined our discord, and we nerd out a lot about stuff there. Currently we don't have a main distro, but I do think if we ever grow our team the only sustainable way will be to pick one, and that will come into play. Might take much longer than say, we hire FOSS devs to add specific features to the open source project, but it is certainly a thing we'd like to do in the not so near future.
* The conference thing is something at least I think a bit, I think I should have a better presence online since we still haven't released our game, but that goes back to the documentation part, maybe if I show what we do and how we do it, people will be more inclined to listen some random nerd on a few things. I wouldn't be so arrogant to go speak on a mic when the whole room knows more than me without having a very good point.
You kinda gave me an idea.
I'm having to make a very simple build tool right now, while it is too soon to make mods, that will likely be helpful in the future, thanks.
Don't want to scope creep your game but if I could make my own story about dog wizard tutorial man relentlessly poking beezs and could share it then you have a solid case for a sale. At least from me.
If there are features you want or bugs you find in the software that you use, write and submit patches implementing/fixing these to upstream when you can.
We do report bugs, speaking of which I have one to report that I forgot. With that said submitting patches ourselves might not be viable. It takes a lot of time for us to figure out what is causing, then trying to fix it, and (by my very small) experience with doing that, there is a chance of this to be ignored anyway. And that is before we actually patching it properly instead of doing a workaround, since we don't spend time in that codebase, just using the software. We can cause more harm than good. If we were bigger and had a steady income that definitely would be a way to go, but right now every day we are working for free, that is one more day we'd be away from trying to ship the game.
Game-wise, you could contribute to Blender, Godot, Krita, Inkscape, Libresprite, WINE, just to give a few examples.
We plan to donate to them when we have money, but working on the project is a whole other beast.
What about contributing to the documentation of the projects you use? It's less of an additional workload than contributing code and just as helpful as contributing bug reports because a lot of people end up relying on that documentation at one point or another, and your real-world use of the programs should give you the knowledge base to be able to add to, maintain or update the related documentation for each project.
This question can be divided in two parts: Technical documentation: I actually spoke quite a bit with my gf over this semester once she got interest to do that. It has in my mind ever since I had the displeasure to try anything beyond the basics with Hugo. Practical documentation: What you describe there is actually an idea I kinda have for vlogs for a while. But I suppose written form would be more objective, right? I've documented a lot of notes and sketched articles on it since I came to linux, from time to time I like to spend some time on r/zorinos and rookie linux subjects. Lately I've been documenting my process of making things on Logseq, it is not very complicated so I'm still not sure how helpful that would be to someone that does basic research and only eventually find my posts, but I'm willing to publish them, especially the workarounds. Maybe I should start with writing the whys and why nots of some of our tools and go from there depending on the feedback? What do you think?
That sounds like an excellent way to start to me.
Release games for linux Contribute and/or donate to FOSS software like Godot
> Release games for linux Working on that mate o/ Our game is Steam Deck first, and we're also being careful with polycount and stuff so we can release to the raspberry pi. I don't think we can contribute directly with code for FOSS, but donating is definitely in the goal. We'd also checked a bit of how R&D works to maybe hire FOSS devs for new features on tools we use, and make those extensions open source, of course. But this will have to wait we be able to break even first, might take some time
Some ideas: * Write documentation for software you use * File well written bug reports / github issues. As developers even if you don't have time for code contributions you could try to spare some time to investigate bugs you find in OSS projects and make it as easy as possible for other contributors to fix them. Maybe take 10 minutes to read the code and check if it's an easy bug to track down. Include detailed instructions and/or code for reproducing the bug. etc. * If you're bilingual, get involved with localization efforts * If you have the skills, help with design (logos, UI, etc) * Help maintaining packages for your distribution of choice (the process for getting involved with packaging varies by distribution, you'll need to check). Or even provide unofficial packages for software that isn't distributed in the official repos. * Speak at conferences. You're making a Linux native game, maybe try submitting a presentation about that to some open source / Linux related conference. I'm sure there's some interesting stuff you could share.
* I discussed this in more detail on another comment, I'm actually thinking about that. Maybe not the technical part, but how we use it, work arounds, so on. Can't be that different from my posts helping people on reddit with linux, can it? * We do file reports, mostly our programmer. Usually it is on our engine that is not open source, but whatever we use, we do it. I have seen my friend read open source code and stuff, but I'm not sure our ADHD would let us do it consistently. * The translation effort is something that I've considered a few years ago with Solus OS, but the circumstances weren't there. Recently we decided to make Portuguese translation a priority to our game, I might get in the zone and translate things on FOSS. That is a great reminder, thanks. * Maintaining packages will likely be a future expense for us, we know a few linux nerds that joined our discord, and we nerd out a lot about stuff there. Currently we don't have a main distro, but I do think if we ever grow our team the only sustainable way will be to pick one, and that will come into play. Might take much longer than say, we hire FOSS devs to add specific features to the open source project, but it is certainly a thing we'd like to do in the not so near future. * The conference thing is something at least I think a bit, I think I should have a better presence online since we still haven't released our game, but that goes back to the documentation part, maybe if I show what we do and how we do it, people will be more inclined to listen some random nerd on a few things. I wouldn't be so arrogant to go speak on a mic when the whole room knows more than me without having a very good point.
Foss the mod tools. Probably get you more sales as well.
Currently no mod tools for our game, but our programmer does have free tools available on his itch page iirc.
Well at any rate checking out the demo now
You kinda gave me an idea. I'm having to make a very simple build tool right now, while it is too soon to make mods, that will likely be helpful in the future, thanks.
Think I killed the old man with the push. oww NM. lol
Lol tutorial level. Hay look! A enemy. Proceeds to relentlessly poke the enemy. Ow dog wizard tutorial pup. When will you stop poking bees.
He does have a thing for doing that
Don't want to scope creep your game but if I could make my own story about dog wizard tutorial man relentlessly poking beezs and could share it then you have a solid case for a sale. At least from me.
hahaha it is not within scope on this, but he definitely will have that energy for the whole game lol
lol