How To Make Your OS Project Successful: Difference between revisions
Jump to navigation
Jump to search
(Created Page + Added Basic Sections/Info) |
(Added some more information) |
||
(One intermediate revision by the same user not shown) | |||
Line 1: | Line 1: | ||
=Basics= | =Basics= | ||
*An Article by hfhfr, on OSS, but applicable to OSH | *An Article by hfhfr, on OSS, but applicable to OSH | ||
=Analysis= | |||
* "First off, have the right idea and build something that solves some kind of common problem. . It helps tremendously if you’re going into some kind of problem area without a lot of existing solutions. " | |||
**Essentially don't enter a flooded market (at least untill becoming well known) due to it being harder to break out | |||
**Also if you are making a good fix for a need PEOPLE TEND TO USE THAT SOLUTION | |||
*" Be as openly transparent about the project as you can early on and try to attract other contributors. Don’t go dark on a project or strive for perfection before releasing your project or starting to talk about it in public. " | |||
**Clear documentation, and effective pr are key | |||
* " Or just as valuable, try to get yourself some early adopters to get feedback and more ideas about the direction of the project. " | |||
** "real world" feedback helps find problems you can't see, and helps make the product "fit" better | |||
* " This deserves its own full fledged conversation, but make sure there’s enough README documentation and build automation to get new contributors up and running fast in the codebase. " | |||
**Readability/Clear Layout of Documentation is key for new people (granted technical pages are technical etc, and jargon can be needed, but have a good basics section + navigation section + organization etc) | |||
*"Try to be responsive to user problems and questions. This is a “do as I say, not as I do” kind of thing" | |||
**Leads back to feedback, but in a more constant flow | |||
=See Also= | =See Also= |
Latest revision as of 18:48, 19 April 2020
Basics
- An Article by hfhfr, on OSS, but applicable to OSH
Analysis
- "First off, have the right idea and build something that solves some kind of common problem. . It helps tremendously if you’re going into some kind of problem area without a lot of existing solutions. "
- Essentially don't enter a flooded market (at least untill becoming well known) due to it being harder to break out
- Also if you are making a good fix for a need PEOPLE TEND TO USE THAT SOLUTION
- " Be as openly transparent about the project as you can early on and try to attract other contributors. Don’t go dark on a project or strive for perfection before releasing your project or starting to talk about it in public. "
- Clear documentation, and effective pr are key
- " Or just as valuable, try to get yourself some early adopters to get feedback and more ideas about the direction of the project. "
- "real world" feedback helps find problems you can't see, and helps make the product "fit" better
- " This deserves its own full fledged conversation, but make sure there’s enough README documentation and build automation to get new contributors up and running fast in the codebase. "
- Readability/Clear Layout of Documentation is key for new people (granted technical pages are technical etc, and jargon can be needed, but have a good basics section + navigation section + organization etc)
- "Try to be responsive to user problems and questions. This is a “do as I say, not as I do” kind of thing"
- Leads back to feedback, but in a more constant flow