I think that adding a (permissive) license is the missing step from this "tutorial". If you want people to use your project you are going to need to give them permission to do so.
Permissive licenses attract the broadest range of contributors, so if you're looking to build a large community, they are the way to go. GPL tends to have a smaller overall, but very strong pool of contributors, so if copyleft makes sense for your technology, by all means use it.
Just use a license, please.
Chances are a personal OSS project will only attracts a few dozen users and maybe a handful of contributors (contributing mostly small bug fixes) with the creator as the only real developer/maintainer.
There is also a good chance that the maintainer will only contribute from time to time after the initial "dev sprint", if it doesn't abandon the project all together.
Basically the bus factor for such projects is 0. If you are relying on one of them, you should be aware that you may have to maintain a fork on your own in the future.
Given this state of things, I prefer having permissive licenses (ex: MIT) on my projects. It's a way for me to give complete freedom about what you do/want to do with my piece of code (piece of code that I may have abandon but is still useful to you). You can fork it and keep the fork OSS or you can include it inside the source tree of your product and maintain it that way, the later being generally easier.
Also if it's you are the originator of a project what's stopping you from using the GPL license but not disclosing your own source while you commercialize?
Or companies adding closed source features to open source software. You can't do that with GPL unless you own all the code.
The classic business plan for software is to charge per license/copy. But if you release your software for free, you have to sell something else. And anyone who come up with a good solution for this will be the next unicorn.
Fortunately GitHub helps you quite a lot nowadays with choosing the license for your project.
In my experience the GPL advocates completely ignore the concerns of the BSD people. The BSD people understand the GPL concerns they either don't think they are very real world (they will acknowledge some exceptions when forced to); or more pragmatically think that the GPL: concerns are outweighed by other concerns.
You need to figure out where you stand. Calling the concerns of the other side FUD is in fact not helpful.
Um ... people who advocate for GPL are not a uniform group.
> Calling the concerns of the other side FUD is in fact not helpful.
I fully agree with that statement, though.