Idea of "software maintenance" comes from thinking that software can be managed in same ways as any engineering project. Each such project has a lifecycle:
- Requirements analysis
- Design / Planning
- Construction / Implementation
- Usage / Maintenance
This means, after the project is finished, some effort and resources are necessary to keep it in fully working conditions. But in all cases, the amount of resources needed for maintenance is small compared to actual implementation. Imagine a big building or complex machine. Yeah, you might want to repaint it or replace some parts, but generally speaking it will remain same for all of its operational lifetime.
So if you assume that software too is an engineering product, then it also has a maintenance phase. The problem is, the assumption that software is same as any engineering project has been confronted many times already. One of the issues related to "maintenance" is that software is so "soft" that it can change drastically even after it's implementation phase officially ends. That is the reason why some people consider "maintenance" to be majority of the effort. Because even though on paper the software is "finished" it is so easy to change it that it will be changed.
This is why most modern software development methodologies don't really have such engineering structure and assume that software will never be "finished" and that it can change drastically at any point in it's lifetime. Even after many years in production.