Beside the good legality-oriented answer above, there is also another facet to the issue: why does someone want to buy your software, especially if a FOSS equivalent exists? This is not a simple question, and history shows that many projects that wanted to attract community by being open and having a value-added version that is closed and for sale, brought upon themselves frown from the community ("are we your free lab rats?") quite vocally, not sure about the commercial side (they are usually under NDA and quiet, or otherwise not as socially active).
I am not really aware of projects that would provide as a FOSS or sold "closed-source" variant the exact same codebase, but this is logically just a first-step subset of having a closed commercial value-added product, or many such in case of customizations per customer's needs. Note that "closed" is not a requirement for "commercial" - based on your written agreement, the customer can effectively sponsor a feature they need and you still have it in the open. On the up-side, if their feature is exposed to the public and eventually someone improves it or fixes bugs, the original "sponsors" also benefit like anyone else in the community. Conversely, even if someone pays for development of their new tool, or buy/license the use of one you made earlier, they may have or not have access to its sources - it is all discussed in the contract you would have.
This brings to the "why buy?" question. From what I've seen over the years, major reasons include:
indemnification - someone to blame in case of errors, others' copyrights and license violation claims, etc.
support the author - hoping for more goodies to come out of this source :)
support the client - a customer can not/does not want to burden themselves with builds and modifications of your open source codebase, it is just not their business. If something does not work or something they need is missing, it is your job (as a proven expert in the area) to make it happen. Often for an added premium, depending on the agreement, though some things can be part of the original sale (e.g. N-year warranty coming with the license, or right to upgrade to any release of same X major version while you iterate X.Y.Z, etc.)
really private "forks" with customizations and features needed by this customer, and unknown to their competitors. Even if they did not actually change anything, with your or others' help, nobody really knows, adding to the "muddiness in the water" as a protective scheme from peering eyes (what do they use? where are they heading? is this a really used building block or something just bought to mislead "spies"?)...
In fact, there are quite a few projects out there licensed very permissively (e.g. with a MIT License, or BSD, or indeed one of Apache ones) so effectively anyone can do anything with the sources with few constraints (e.g. embed into their proprietary codebase and just mention that your work was used). Sometimes they are "one-man shows", sometimes large industries like the Jenkins core and plugin community, or the *BSD and illumos OS ecosystems, which actively intend and help to give the code away for any use (or some extent thereof), and the people in community make money by consulting, maintaining, customizing, etc. for the willingly paying users. Or they are employed by such users. Or they make it for the fun of it in the afterhours and just want to see their work spread and be used (well... TBH "seeing" is not that easy when people don't even have to tell you).
While "forks" of such projects are not required by license (like in GPL-licensed projects) to open the sources or commit back to upstream, this still happens actively in practice if only as a way to easily synchronize your fork from the upstreams eventually, have your changes revised by more experts, and maintained by someone else in the long run (non-regression as new features are added in upstream).