They start out small and open. Then, as more people adopt them and the tool is extended to meet the additional requirements of the growing community of users, eventually things like access management and digital rights start getting integrated. Boil the frog. Boom. LMS.
If you build a great little educational app and it gets some traction in the market, sooner or later, somebody is going to say, “This is great, but it would be even better with an announcements tool.” And somebody else will say, “I’d really love to be able to have a place for class discussions.” And another user will chime and say, “Discussions would be great, but I’d like to grade student participation. Oh, and I also need an assignments list. Which would ideally show up in some sort of a calendar.”
On and on it goes. The app development team recognizes at some point that they are building features that are redundant to those of an LMS. But context is everything, and the users want these capabilities put in the right spot in the app, in the right way. So the developers keep building. And building. And building. Many of these features are not the ones that the developers think make their app great. But they have to be done. So they are. Often quickly and badly. And even if they are done well, the cumulative result is generally bad because the app was never designed to be an LMS and, after a while, all those unanticipated bolt-ons make an unholy mess of the user experience. Which the developers never have time to fix because they are always busy adding the next bolt-on.