There have been discussions about centralising the nim ecosystem around either a Nim Foundation (way back when), or a nim-community, or any other centralised-but-open structure, which would work to conserve sanctified packages, social norms, and whatever else.
I have been verbal about my disagreement with such actions or trends, specifically in this thread, and I finally got the time to write down in more detail how I perceive these systems, and why I think that centralised-but-open is a net-negative on Nim, and on any other (soft)ware project.
https://aethrvmn.gr/blog/supermarket/
Hopefully people don't consider this as self advertising (the code is on my git server so you can see I don't care about analytics, visits, or whatever), however I do hope to finally settle the discussion by saying "Please don't make Nim a supermarket".
Analogies are kind of fun and can provide a (simplified) view of a reality as a starting-point of discussion. However they are still a simplified mapping the reality, and usually not encompassing all important aspects of that reality. Also simplified analogies tend to be used in populistic settings (like chainsaws) and may shift content-based conversation to a popularity-contest and power-logic, thus endangering nuanced discussion.
I would like to ask, if you had an early-born baby that needed incubator-care, would you want the staff to be of supermarket-type or would want it to be of bazar-type?
I would want it to be of supermarket-type, because I would want my baby to get well-planned, organized, and guarantied care.
In a bazar-setting, a great new incubator-type would be designed by some enthusiast, but he would forget to feed the baby on-time. Other stall-workers would create beautiful decorations, but forget their babies as well.
In other situations a bazar-type org might work. For example in research-org, or in an art-setting. But it is not advised in a context where you need guaranteed levels of service or production.
So a simplistc one-size-fits-all analogy is not going to work.
That being said, the aspect of small is beautiful is still an attractive design-principle, like the kiss-principle (keep it simple, stupid). But then you talk about questions of partioning and refactoring. It remains important to keep thinking about ways to (re)partition complexity in handlable blocks that can be drop-in-replaced. Maybe that is also a part of the idea you want to convey. That also encompasses discussions about interfaces (between these blocks), their definitions and maintenance, which may be a different area. The interface-maintenance itself may also require some supermarket-attendance, but it may facilitate bazar-tactics for individual block-development.
@nasl No, my point is that in a "the bazaar" style of structure, you MIGHT end up with a thriving community, and with a multitude libs/bins of varying quality, which aren't necessarily blessed by a central "management". I don't like central management, as I feel it creates social expectations in a technical field. For example, if Nim had "The Nim Foundation", and "nim-community" hosted centrally, as the de-facto blessed org for hosting projects, you would have grabnim be seen as a "challenge" to the "blessed" choosenim. Now, in the "nim bazaar", grabnim can co-exist and exceed choosenim to the point where most people suggest it instead, without the need for "Do we need to change the correct way to handle things? Why didn't the dev contribute to choosenim instead???? Usecase for another version manager?" etc.
@Hobbyman metaphors exist to create a basic idea as you said. Because your question is on a base of supply chain logistics, I have to be clean and say that if you expect me to behave in a specific way, you have to pay me to behave in a specific way.
Socially conditioning and shaming volunteer developers so that you keep your "supply chain" proper is a net negative. People need to remember that the software they use has a:
"THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE."
If you want people to work for you, pay them. Then they will happily design and maintain your baby-incubator.
What is the task of management?
A good friend of mine has a large design bureau. He started it after he was fired from the job. Very successful and after a few years he hated it. When he told me, I advised him to hire a retired CEO with the promise of the lowest pay and the most fun. In he end, after a burn out he did. He's not a manager, he's a designer and loved to work with other designers on projects. He was unable to communicate with people from different fields, bankers. That is the main task of management. Translate needs into something other parties understand and vice versa.
Managers are translators and facilitators. They pave the way. They are not dictators.
I have been thinking about flexibilization and enabling bazar-tactics whilst keeping quality-control. As managers like acronyms i have thought of some. Firstly i thought of BBIND (blocks, boundaries, interface, negotiate, definition). You can negotiate (and agree upon) boundary-definitions and interface-definitions between blocks (two linked boundary-defs from two blocks form the interface-definition). A boundary-def also must include valid value-domains and rules for error-handling of out-of-domain values. Also some generalized and validated way to test the blocks would be nice.
But this can be very complicated and a rather synoptic approach, which usually walks behind the facts (the situation changes and the interface is deprecated). Also programmers usually dislike prescribed interfaces and their documentation. It is still to inflexible and legalese.
Next I thought of IRAs (intermediate result agreement[s]). This means not a complicated interface has to be agreed upon but just an intermediate result; it can be a text-file or some piped output (i am not a computer-scientist). It may be a bit slower but it is a flexible, decentralized and non-legalese approach. A network of IRAs could provide the flexibility of a bazar but omit the legalese-ness of interface-definitions (or even monolithic approaches). Programmers like file-like structures and find it natural to work with them. They are self-explanatory and example-based.
I am not a computer-scientist (forgive me if i am talking non-sense) so i dont know what would be the best in-memory "intermediate-results" for optimal speed.