I've been meaning to write this for a while... Recent discussions spurred me to get on it. I present: "What To Expect When You're a Platform Library Maintainer" Having your library as part of the Platform has its plusses: * Your library will get lots of users, which in turn will get it used, tested, and maybe some contributors. * That functionality becomes part of what developers perceive as "easily doable with Haskell" * Fame! (Well, functional fame...) There are downsides too: * You'll get bug reports. Some real, some bizarre. * You have to subscribe to a low-volume mailing list. * Every six months or so you'll get e-mail from me asking what the current stable version is. But the real thing to think about is the responsibility: * Once in the platform, we're telling people to use it and depend on it... which means you need to be sure it is dependable. * You are committing to keeping the API stable. Which means long term (years) forward and backward compatibility: ** Clients written to your API today should continue to compile and work against future versions of the API, several years running. ** Clients written to your API today should be able to, without much trouble, work with the past few (2? 3?) releases of the platform. * You can only depend on other packages that are in the platform, and are committing to that restriction going forward. (That isn't to say that you can't lobby to get some other package you'd like to use into the platform... but just don't assume it will.) * Your package should help work toward eliminating "cabal hell". This generally means adhering to the PVP, and having reasonable values there. * Tests. Please. * You should have a public repo on GitHub or someplace with similar availability. * You should have a contact e-mail publicly available. If you want to stay anonymous, having a package in the platform isn't the way (see "Fame!" above). * You aught to have back-up maintainers. That way if you are on vacation or need to take leave or give up the project - there is someone else to keep it going. * Twice a year expect a short flurry of messages and checking to make sure all is well and compiles with the latest of everything else that goes into the platform, including GHC. For many this is usually very little work... then occasionally GHC 7.n+2 comes along and we all have stuff to do! I know it sounds like a lot, but isn't that bad, and it is worth it: Successful programming systems (think PHP or Python or Java) have succeeded in large part because they have a rich set of platform libraries that "just work". It is the development experience with that platform that makes developers decide a programming language is viable. The success of Haskell will be largely based on how much we can all pitch in to make the platform libraries a "smooth sailing" experience, "batteries included". - Mark