I feel Duncan Coutts is right. Just fixing deps could be done by anyone. Bigger changes (design choices) about more complicated packages should be done on forks till the maintainer replies or failed doing so for some time. However live must go on in such case, too. Thus forking seems to be the best way to continue. Then it should be possible to signal that there is an alternative upstream for that possibly unmaintained package. Maybe a cabal field such as improves-uppon: other-package If the maintainer replies it can be deprecated and upstream can be merged easily. There are different approaches, too. Eg github/bitbucket support teams/organizations. Eg the haskell community could just start a such a team which implies that all packages hosted there may be updated be the community as well (unless there are special notes in the .cabal file/readme). Its not only about putting updated packages on hackage, also about knowing where current upstream is (if others want to join its easy to miss such a fork) - with a community bitbucket the new version could just be a new branch .. How well such works in the real world - no idea. In the Vim community there are severall packages whose maintainers changed and where 2 to 3 people fix some small bugs occasionally. Marc Weber