This means that we tend to focus on treatments for currently untreatable cancers, and once we have something that is semi-OK, the rate of improvement goes way down. It doesn't go to zero, by any means, but the incentives shift in a way that is both perfectly logical and kind of perverse.
It's called the law of diminishing returns, and applies to nearly everything sadly
Two things:
1. The cost of MS license in the third world is really high comparatively, even with academic and non-profit discounts. I've worked at a school in South Africa where the licensing costs of a small lab could have hired an extra teacher. You don't get academic/non-profit discounts if you buy once-off licenses, to get those you've had to go with subscription model since at least 2003
2. The support offered by Microsoft at the school did not cover desktop support, or if it did, that support was so slow in coming as to be useless. That's one reason I had a job. IN this case using off-the-shelf software carries no support advantage, and little usability advantage. Chances are nobody at the school can use a Access, or even excel particularly well. From the original poster suggestion of running it on a VPS I assume they have internet, and are probably more familiar with a browser and word than excel.
All that said, the idea of just using a spreadsheet makes a lot of sense. From a reporting perspective, it makes life easy, and getting data to UNICEF et al is as easy as emailing a copy. I'd avoid Microsoft though, and go with libreoffice.
If you are into learning, and don't already have a specific goal you can work towards, I strongly suggest re-inventing the wheel, specifically the file manager wheel, it covers a LOT of ground and will earn you invaluable experience. After writing one you will have solid experience in
Notably, this lacks some other fundamental stuff to programming: SQL (a little knowledge here goes a long way too), graphics coding (the basics I learnt before openGL have stood me in good stead over the years), and I'm sure there's more. Still, a file manager is a good choice IMHO
"Many eyes makes bugs shallow" applies not only to people working on the buggy code itself, but also all the developers who use the code. Bugs are almost always almost found because of software behaviour, and in general bugs in closed or open software are equally likely to be discovered by end-users. Bug are far more likely to be found by developers though. Consider some different scenarios: (1) A bug is discovered because following the documentation on how to use some API doesn't work exactly as expected; a really bad bug because behaviour under normal conditions is wrong. (2) A bug is discovered because a developer makes an invalid call to an API and it doesn't error out gracefully; still a bad bug, but most developers are going to correct their code to use the API correctly, and maybe file a bug report if the problem is bad enough to break their software. In case (1) someone is always going to file a bug report, closed or open source doesn't matter. In case (2) is different; chances are a developer isn't going to bother submitting a bug report if the buggy code is closed source, they'll just write some validation around the API call to avoid the bug before it happens. If open source, this validation will probably be submitted as a patch upstream, or at least someone is likely to report the bug. But then there's case (3), heartbleed. What you've got here is a bug that for correct input works, no bug to file, for incorrect input appears to still work, so still no apparent bug, but for incorrect input it does extra stuff you don't know in advance to check for. A developer with a case (3) bug is far less likely to discover that bug. If the library is open, a developer debugging their code might step into the library code and see the problem, slightly increasing the likelihood of the bug being found in open source as compared to closed.
The point is that downstream developers count as 'eyes', and probably make up the majority of those eyes. Because of lower barriers to entry, open source projects when compared to their equivalent closed-source counter parts tend to have many more downstream developers. Even is the case of non-library, end-user application projects, other devs are write plugins, extensions etc. so this remains mostly true. The argument that the eyes don't exist is not true. The eyes may not be looking directly at the code, but the code's behaviour is being tested in a variety of other ways. Case (1) bugs are going to be found and reported regardless of whether the source is open or not. Case (2) bugs are probably equally likely to be found, but far more likely to be reported and fixed if the buggy code is open source if there is a downstream workaround. Case (3) bugs are hard to find either way, but are MUCH easier to fix in the open source world.
All seems condemned in the long run to approximate a state akin to Gaussian noise. -- James Martin