What To Expect When You're a Platform Library Maintainer

[Mark Lentczner]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140409/b115f3f2/attachment.html>