My summary here would be that both are good, for different things. If I was deploying a personal site or a personal app, I would probably go with a VPS, because it's easier to set up, and can be a lot cheaper. But if scaling or uptime was a concern, I'd want to go the PaaS route. It comes with a few upfront costs (configuration, statelessness, price, etc) but is absolutely worth it in the long term.
I am dyslexic, and have struggled with reading all my life. Saccades are physically exhausting for me, and so I get fatigued quickly. I also subvocalise, which slows me down to 180 wpm or thereabouts.
RSVP is helpful because it removes the need for saccades, and so reduce fatigue. They also force you to stop subvocalising. As a result, I am able to read at 600 to 700 with high comprehension now. And over 1,000 to 1,200 wpm with enough comprehension to be useful for things I just need the gist of.
1,200 wpm. It's crazy. I never thought it would be possible. But I suspect that if I continue to use RSVP, it will have a profound effect on my life. There is so much stuff I do not read, because I find the normal experience so painful.
I agree that industrialised farming is very upsetting. (I am a life-long vegetarian, by the way!) Have you watched the film Samsara? To quote Jason Kottke, some of the scenes give a "full visual meaning to the mass production of food."
But the analogy holds. On any sort of farm (even a vegetable farm) units of production are fungible commodities. And it turns out that this notion of fungibility is very important in post-virtualisation architectures.
The most important thing I wanted to communicate was that active contributors are very important for a healthy project. And that if you add people to a project, the project stands a chance of outliving your individual contributions to it.
If a project required constant fixing because, say, the code was very bad, then yes, I agree that would be a bad sign. But I was primarily thinking of dependency maintenance.
I took a look at ncurses to see if I could learn anything about their success.
I count 18 contributors in the README file, which is exactly the sort of thing I was thinking about really. Seems like the package has been passed from one maintainer to the next as people's situation changes. This sort of thing is important! If ncurses had met with the same fate as most GitHub repositories, nobody would use it any more. It would be forgotten about.
I took a look through the configure.in file too, and it looks like ncurses has very few dependencies beyond requiring a sane build environment. And I see that ncurses releases once every few years, and has been doing since the 90s. Oh, and the mailing list seems alive and well.
All in all, ncurses seems to be exactly the sort of healthy project I was thinking of. Regular contributions, shared maintenance, very few dependencies, and a predictable release cadence.
Indeed. Commercial contributions are very valuable, but it's important to take steps to reduce the inherent risk. If AcmeCorp stops paying its employees to contribute to your project, do you still have a project left? If that thought scares you, it's a good indication that you need to increase contributor diversity. Perhaps that means more volunteer contributors, or perhaps it means additional corporate contributions. But do not put all your eggs in one basket!
It is possible to reach feature-completeness. TeX is probably the most well known example of this. It was feature-frozen at 3.0, and the only changes made now are bugfixes.
The problem arrises when the things your program depends on go away. For example, if you have a project that is written for Ruby 1.8.7, after June of this year, that version will receive no more updates. If there's some particular feature of 1.8.7 that you depend on, or some bug found, or some security vulnerability discovered, users might eventually find themselves in a spot of bother.
The web of dependencies for most projects is bewilderingly complex. The stacks that we write for are moving targets, and unless your software is moving to keep up, eventually there's a good chance that they just wont run any more.
This sort of thinking is why the IETF publishes Internet Drafts as ASCII-only text files. They've limited the dependency chain to ASCII, because they are hoping that isn't going away any time soon.
I'm sure there are plenty! You could start by picking a project on GitHub that seems interesting. Have a look at the open issues to see if there's anything you could fix. Most repository owners will be very grateful for pull requests, and are usually happy to provide feedback on your code.
If you've removed any language suggesting that this should be used to gain and exploit unauthorised access to somebody elses Facebook account (I presume that means you will be registering new domain name for the app) then what is the point of it any more? Why would I want to click a button to post a bunch of fake stuff to my wall? That would be like #poopin yourself. Utterly pointless.
If it doesn't encourage, it certainly enables. The whole point of the site is to let you exploit unauthorised access to somebody else's Facebook account. The footer is a non sequitur.
The other options allow you to post content on someone else's behalf, without their consent. That is unauthorised access, and probably against their ToS. I would be extremely surprised, and concerned, if it was not.
Your footer is just hilarious of course. You claim that you do condone unauthorised access to other people's Facebook accounts, on a site who's only function is to let you make unauthorised access to someone else's Facebook account.