Well, since it takes at least a year of working together, in order to know someone well enough, recruiting people for other open-source projects or even commercial ones, is never a short-term goal. It is indeed much more about working with people that you clearly get along with, and who are also interested in the same things, than money. I look at bash in a completely different way, because after dealing with linux process groups, aka "containers", for almost two years, I can see what you can do with bash, that you would be hard-pressed to do with other languages. Microservices, aka "distributed computing", is a different ballgame from other programming situations. So, someone with just experience in single-machine programming may indeed think that bash is a weird tool, until he has to orchestrate an entire swarm of collaborating containers. One reason why clients are willing to pay so much for Docker-type architectures, is because it is so incredibly harder to attack a swarm than just a single machine. Container walls are almost as impenetrable as virtual machines, and if an attacker has to penetrate a dozen of them ... not everything in the world is just a Wordpress site ;-) So, my short-term goal is to get the open-source publication out of the door, and my long-term goal is to know enough people that I have worked with, so that it would be easier than now, to find people to work on something.

Yes, but if you do not really believe in it, would you truly be willing to spend time on it? I mean, it always takes will power and determination to finish any programming project, no matter how small. Where will you find that will power? One reason why I am paying, is because it will work with quite a few people, to keep them on the project, and get them to bite the bullet anyway. Otherwise, they may just abandon at the slightest obstacle. So, 80% of the motivation should come from believing that it is a good idea, and 20% from the fact that it gives you some pocket money anyway.

Furthermore, I want to meet people who turn out to be really good programmers, so that I can do new projects with them, or even propose them for the commercial projects that I work on. It is way less dangerous to get to know each other on a free and open source project than to end up losing face with customers. The latter is usually way more expensive than anything you could think of. To a very important extent, I live off my excellent understanding with particular clients, and therefore, I want to carefully get to know people by working with them for a realistic period of time on non-critical things first.

What you are asking doesn't sound too complex, but why do you want to do it in bash?

It is a bit of a long story. It is about notational purity, and favouring process chaining over function chaining, but I can really not explain it in five minutes. I will just give a quick example of where I believe the true power of the shell lies:

$ ls -l 
$ ssh john@myserver ls -l
$ echoExec ssh john@myserver ls -l
$ shutUp echoExec ssh john@myserver ls

The amount of time you'll spend reimplementing (and testing!) existing, mature libs is painful.

Well, the amount of time to reimplement bash in other languages is even more painful. Try to do this in other languages:

while read f ; do
     scp root@myserver:$f otheruser@myserver2:/tmp/$(basename $f)
done < <(ssh root@myserver myprogram arg1 arg2 arg3)

In a distributed microservice architecture (such as Docker) you really do not want to use any of these other languages.

The advantage of favouring process chaining over function chaining is that you can chain processes while they are running on any machine (or in any container), and combine them with processes running on any other machine. That is probably why even Microsoft has become so fond of bash and shell scripting. If you ever read the Docker documentation you will very soon understand that you would impossibly be able to orchestrate a reasonably large number of microservices using any other tool than a shell scripting engine.