Thanks for leading this. I can't wait to play with and hopefully integrate this into our project at http://itsme3d.com - it seems like Christmas has come early this year.
I do have some advice for you, though: you need to tell the story. In that story, you need to start with why.
While your GitHub README.md is better than the project's homepage, both currently fail to answer the most basic questions about Whitestorm.
- is this for me? am I the target audience?
- what is the reason this exists? what are some real use cases? is this an experiment, a hobby or something I'd use in production?
- how hard is this? what is the minimum viable amount of time/energy required to get started?
- one of my favorites... "what tool I use does this replace or improve?"
- is it ready today or should I come back later?
- what is the cost? (don't assume everyone "gets" open source)
More significantly, I believe that every project should start with the origin story. Who are you, what problem did you have, how did that turn out, how did things evolve to get to the iteration in front of me? Why was this problem so important to you? Make it personal. Use "I" and "my". Talk about your goals and ambitions. Don't use "we" or terminology that is designed to make you sound more legit. Software is designed by people and people make decisions based on shared values.
Make sure that your plugins are well documented. Make sure that your examples are plentiful. If you have time to write an example then you have time to write a few lines about what this particular example is showing me. Also, something nobody does but I wish that they would is to use comments to tell a story and mark off sections that differ from the boilerplate template and explain what you did to make it work.
The hardest part of launching and promoting an open-ended platform is that there's a tendency to tell people it can do "anything they can imagine". The problem is that they have no constraints on what's possible and most people are not intuitives so they only see things as they are instead of what they could be. You need to give them just enough lightbulb moments that they start to learn what's safe to imagine is possible with your software.
When you create a platform you have to give people a path to happiness and success that calms their reptile brain and gets them excited to be a hero. The burden of proof that they should trust your software for the long haul is on you.
Thanks for leading this. I can't wait to play with and hopefully integrate this into our project at http://itsme3d.com - it seems like Christmas has come early this year.
I do have some advice for you, though: you need to tell the story. In that story, you need to start with why.
https://youtu.be/IPYeCltXpxw?t=15s
While your GitHub README.md is better than the project's homepage, both currently fail to answer the most basic questions about Whitestorm.
- is this for me? am I the target audience?
- what is the reason this exists? what are some real use cases? is this an experiment, a hobby or something I'd use in production?
- how hard is this? what is the minimum viable amount of time/energy required to get started?
- one of my favorites... "what tool I use does this replace or improve?"
- is it ready today or should I come back later?
- what is the cost? (don't assume everyone "gets" open source)
More significantly, I believe that every project should start with the origin story. Who are you, what problem did you have, how did that turn out, how did things evolve to get to the iteration in front of me? Why was this problem so important to you? Make it personal. Use "I" and "my". Talk about your goals and ambitions. Don't use "we" or terminology that is designed to make you sound more legit. Software is designed by people and people make decisions based on shared values.
Make sure that your plugins are well documented. Make sure that your examples are plentiful. If you have time to write an example then you have time to write a few lines about what this particular example is showing me. Also, something nobody does but I wish that they would is to use comments to tell a story and mark off sections that differ from the boilerplate template and explain what you did to make it work.
The hardest part of launching and promoting an open-ended platform is that there's a tendency to tell people it can do "anything they can imagine". The problem is that they have no constraints on what's possible and most people are not intuitives so they only see things as they are instead of what they could be. You need to give them just enough lightbulb moments that they start to learn what's safe to imagine is possible with your software.
When you create a platform you have to give people a path to happiness and success that calms their reptile brain and gets them excited to be a hero. The burden of proof that they should trust your software for the long haul is on you.
Keep up the great work.