Undoubtedly there are many projects which fail once their initial circumstances are changed by their own success, but this is a universal problem, not restricted to software. There are, however, a number of strategies which appear to be proving successful in keeping software projects on track in the face of success.
Some open source projects respond to success by growing, by using the resources and developers that popularity brings to extend their functionality. Often this "feature creep" extends in only some directions (for example, the Linux kernel project tries to support as much hardware as possible, but is completely uninterested high-level applications) but it can be expansive (for example the Debian project, which has the slogan "The Universal Operating System"). A project aiming for world domination needs very strong leadership, this may be in the same person as the initial developer (i.e. Linux Torvalds of the Linux kernel), or it may be recruited from the influx of resources and developers that success brings (for example various members of the Debian team).
Some open source projects respond to success by herding together, either under the umbrella of third party providers such as sourceforge or to larger projects such as the Free Software Foundation or Debian. The herd can provide technical, social, project management and infrastructure support that small groups of individuals (or even small companies) can't. By being part of a herd of projects, individual projects find it easier to get support from fellow travellers within the herd who are already accustomed to the herd's modus operandi so they can step in to do small tasks relatively easily.
Some open source projects respond to success by refocusing and narrowing the project. Many projects, particularly reference implementations of drafts that aim to be standards, need to freeze their work once a critical mass hs achieved, because their primary virtue is their consistency, and expanding the project undermines it's successfulness. This response requires no great leadership from the project developer(s), other than the will power to resist tinkering. Often developers move to closely related projects that build on or extend the original project and groups of such projects may eventually become a herd.
Some open source projects respond to success by going setting up a company to sell the software or services based on the software. Where ever startup funding comes from (private investors, IPO, etc) it is likely to come with a requirement for professional management of some description. (This is something I really know very little about StuartYeates)