The big feature that artists need is presave links (ones that let you add a release on Spotify, Apple Music, YT before it goes live) and an automatic scan of all streaming platforms based on UPC that converts all the presaves to direct play links automatically.
The big players like Linkfire have this and it's easily 100x the complexity of the link page that this has.
Most artists have so much to do leading up to release day that a manual link page is very far down the list of items they need to pay attention to.
What market abuse? And what do you split up? Apple is a hardware company, all the software they write is purely to make the hardware they sell attractive to consumers.
Who should pay for the cost of development then? Apple has always been very clear, the store commission is for use of their IP. Any other store can undercut apple because they don’t have to pay any of the development costs for the platform.
There is no weaseling, it is very simple: the commission covers the licensing. The alternative is saying that apple must develop software, give it away for free, then let random stores make a profit selling software that they contributed nothing to.
It is exactly equivalent to the EU saying that a company should be free to use GPL software however they like, including selling at a profit, without providing the sources.
Presumably, they could just treat iOS like macOS, where there already is a notarization system that covers apps distributed outside of the Mac App store.
I believe the number one problem you will run into is what happens to every wiki in the world. Knowledge goes stale and discovery is hard. Especially when you don't know what to look for.
Making content is never the answer to passing on institutional knowledge. This problem was actually solved very effectively a long time ago by trade unions such as the masons.
Start by having an apprenticeship program. Shore up any missing skills and teach someone how to apply them at your institution. Go into the meaning of why you are teaching them.
Second, set up a simple progression where one builds a base of understanding to move to the next phase of institutional understanding. Apprentice (learning) -> Fellow (perfecting) -> Master (can teach).
Masons don't even write anything down and have managed to pass on institutional knowledge for generations. Martial arts communities are similar.
Isn't there a catch, at least in the US, that companies don't want to invest in training/mentoring because they believe once they reach a certain level the people will just leave and employees that don't feel like they're being trained/growing in their role will also start to look to new pastures, esp. if pay is keeping up with their skills?
I was recently laid off from my job. I was #2 in a two-person IT team (#1 had been there for 20 years). I came wanting to be mentored and to learn but the string of broken promises and lack of any sort concrete plans left me adrift so I continued to self-train. After expressing this sentiment to the boss, thinking an open and honest dialogue about where I hoped to be and that I felt neglected in terms of the company investing in me (whereas the other users received an educational stipend, paid for professional study and exams, etc.), I was told we'd come back to it after our office move earlier this month. Well, we did, and I was let go.
I don't disagree with your main point, and I think the apprenticeship model could work wonders in many tech environments. Harder to implement when you have a very migrant worker population, even at normal rates of turnover.
There is however some merit to writing down details to critical or seldom-used processes in a communally-accessed place such as a wiki. Keeping it up to date and having someone review it regularly has to be part of the process.
Build instructions, and dependency assumptions for starters.
Sometimes the hardest part is just figuring out how to get a project running, or learning what kinds of settings need to be enabled on deployment.
As for craft and actual in-code understanding, I think the masonry example can fit well (see pair-programming as a more fluid example of this). Granted, if you have an API, you probably want to at least document the interface with an example of how to call it. The complex bits of "how is this architect-ed can be better taught by 1:1.
Kind of cool if this is what you need.