I was just suggesting a way for the article's author and the drive-by quasicontributor to get along, not that it would be a worthwhile product.
Practical value (running a system that does X) vs. learning value (learning to do X) is the main distinction between the two types of projects defined in the parent post.
Yes, I understand where you are coming from, but I don't see the need for creating a third umbrella project to make two projects get along or communicate. Maybe if both parties accept, they can directly implement the interoperability, but my opinion stands.
Anyway, I assume you know that GP is also my comment, but the difference is not Practical Value vs. Learning Value. It's the target of the project, plainly. i.e. Do you want a small tool which you gonna care, or a tool which you'll give away incl. its control.
Learning Value and Practical Value can be combined. I have a couple of tools which I built for myself, with hard constraints on resource consumption, because they run on low end SBCs. However, all of these tools provide a real value for me, because I deploy these tools/services and they handle real world load for me.
I also open source them [0][1], but I'll not accept big patches changing the code fundamentally.
