The best solution, as has been stated, is to get a real web-hosting plan that allows https. This shouldn't be too expensive, in fact it should even be possible to find a free provider to provide this.
Failing that, what is your use case? It sounds like you have a set group of users in mind for your web site. If that is the case and you aren't just offering a subscription-based event notification service to random people on the internet, consider providing the basis for a 'secure' connection on a different channel.
It occurs to me that getting the code to their machine by another, reliable source (posting CD's via snail-mail and informing them via email, simply sending the software as an attachment to a digitally-signed email, etc.) allows you to pre-load the software with a cryptographic public key.
You can then negotiate a secure connection over an unsecure connection method (such as http) since the code determining whether the server has satisfactorily decrypted details encrypted with its public key lives on the client. A stream of 'plaintext' http application data is the result, with the wrinkle that the application data itself is encrypted.
This is a lot of trouble and a non-standard method. You run into problems with implementation since few people will have tried it to offer advice, and with security since few people have reviewed its reliability*.
The alternative channel may itself have security problems. Could mail be intercepted? Could scammers impersonate your organization and send their own, 'secure' version of your software? Are your users savvy enough to check digital signatures on emails you send? These are all concerns you'll need to consider and either accept as risks or attempt to mitigate with novel solutions, as you have less guidance around not only how to implement, but even what questions you need to ask (you'll need to ask more than just these three!).
When talking to the NGO management, consider outlining the situation in these terms:
- The latter method involves significant risk, and will end up costing them more of your time to implement than will simply paying for hosting - the program needs to be updated, especially if the server (or the server keypair) changes, and continually distributed to new users after the initial deployment.
- Doing nothing at all and using a password over http with addresses and names (and potentially email addresses) could be a public relations disaster if any information leaks (and it will), a significant risk. This is compounded by the fact that people re-use passwords and your bad practice could be linked to subsequent breaches.
- You have as such given the situation significant thought and are not just going to suggest the solution outlined in step 4 because 'everyone does it' (although, in the case where everyone does it because it is best practice, this is hardly a bad thing). Being able to propose the alternative (if convoluted and excessive) solution outlined in steps 1 & 2 is evidence of this due diligence being conducted.
- Based on this, https hosting with low (or no) ongoing cost is both the least costly AND least risky approach.
*Jonathan Gray goes into why you will run into issues coding a secure system in his answer, look at the section starting "TLS is also a much more intrinsic system"