Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
This is a common problem with Free software, and honestly I think it's our biggest one: we build stuff for ourselves and stop there. If we want our stuff to be adopted (which, for things that rely on network effects, we do) then we need to pay more attention to usability.
Here's a suggestion for anyone starting a project they think they might share. Before you start writing any code, write the documentation. Then rewrite it from the perspective of the least tech-literate person you know who you'd still want to use the project. Only after you've worked out how easy it should be for this person to get started, then you can start writing the thing.
Ideally, the project should not require any documentation to read.
Yep, I know, I think everyone should read to learn, but I've seen so many times peoples' spark die once I tell them "I will send you the docs with clear instructions. If you have any questions, let me know :)". The reply is often " Oh, but it should tell me where to click".
Or maybe it's because the docs are too difficult, I don't know.
Generally, I agree. I think what I meant by the above is "how would you tell someone how to use the thing". My favourite example is email vs email-with-PGP.
How do you send an email?
How do you send a PGP-encrypted email
Let's first talk about this thing called a "keyserver". Once you know what that is, you'll have to go out and find some keys to add to it. We're not going to talk about styling your message 'cause that's not something you should be able to do... etc. etc.
Good documentation should, in part, tell people where to click. I have designed software documentation for high performing individuals at leading global companies, and I have designed software and hardware documentation for minimum wage fast food workers with limited English proficiency. In both extremes, I showed them exactly where to click on the screen at each step.
You might not need that level of help, but many people do. Others do not strictly need it, but they prefer the simple instruction set. "Click here then here," instructions ease the transition into a new system one needs to learn, or it removes the need entirely to learn a system one uses infrequently.
The problem is that making good documentation is difficult and time consuming. It relies on a fundamentally different skill set than coding or even UI design.
I agree that the ideal is for software to not need any documentation. In my experience, I have yet to see software that rises to that task and is used across a variety of experience levels and societal cross sections.
The docs are not only often difficult for an inexperienced user, they commonly omit points of failure.
Various prerequisites, problematic settings, possibility of the user choosing the wrong menu etc. etc. should always be considered.