{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiflf34bjapclh3di7zjr5qtibtc4nabxxh6ihnuahhfj4uqghahq4",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mf6uabem34a2"
  },
  "path": "/t/fork-basement-as-baseplate/12415#post_13",
  "publishedAt": "2026-02-19T00:26:31.000Z",
  "site": "https://discourse.haskell.org",
  "tags": [
    "the xml library",
    "namespacing",
    "@vincent",
    "@apotheca"
  ],
  "textContent": "taylorfausak:\n\n> This is hardly the first time this situation has happened. Consider the xml library. It hasn’t been updated in over 10 years. Does someone deserve to take it over? I don’t think so.\n\nehh..well what if 1000s of packages relied on it transitively. And something happened (GHC evolution) that broke `xml` and now it needs some elbow grease. Now vanilla `cabal` just doesn’t work (and will _never work ever again_) for a huge part of the ecosystem. Everyone indirectly touching `xml` must now muck around with `cabal.project` or a Nix overlay or whatever `stack` uses for this sort of thing.\n\nSo then let’s say the maintainer is contacted and they say “nah I’m not gonna update it. nah I’m not gonna accept any PRs and push updates to Hackage. nah I’m not gonna hand over ownership or even allow someone else to have the commit/update bit in addition to me.”\n\nthen YES - that’s takeover time. `xml` is a good example here because it, like `basement` and `memory`, is a core building block other projects may stand on.\n\ntaylorfausak:\n\n> To me the only reasonable solution is to allow namespacing packages by the maintainer’s name. Then we could have `@vincent/memory` and `@apotheca/memory` without issue.\n\nNamespacing is cool, but I don’t see how it would be functionally much different here than the whole “fork and rename” approach. The same toil would result - unless I’m missing smth.",
  "title": "Fork `basement`? As `baseplate`?"
}