Rebalancing open source portfolio

Being an open source developer means being an investor. I invest my time in creating, contributing to, and maintaining projects. As an investor, I occasionally need to re-evaluate my portfolio and decide whether it is optimal.

The result of a recent such re-evaluation is that I’ve decided to stop my active involvement in the haskell-suite family of projects.

This decision wasn’t easy. Being a maintainer of haskell-src-exts was a unique experience. During the last two years, 24 people have contributed to the project, which is amazing, given its complexity. During ICFP’14, I met with 4 or 5 contributors and many users of haskell-src-exts. People would approach me in the hallway and ask when the new version would be released or a certain feature added.

Leaving haskell-names behind is also sad. It hasn’t seen as many uses as haskell-src-exts (which has always been puzzling — you can’t do much with a bare parser. But apparently folks prefer to roll their own, incomplete and buggy, name resolution.) Still, it’s used by fay, and I feel bad about letting the fay devs down.

So, why did I choose to stop investing in the haskell suite?

1. I have much less spare time these days, so I have to drop something.
2. I became involved with the haskell suite because of my interest in developer tools for Haskell (hasfix, ariadne). I am no longer working on those, and I’m not using any haskell-src-exts-powered tools (hlint, stylish-haskell) myself, which means I don’t get big personal returns on my investment.
3. The main competitor for the haskell suite is the GHC API. It is now clear to me that we are losing to them in most areas. There is very little hope for the type checker, let alone other parts of the compilation pipeline. The community did a great job in catching up with GHC on the parser side, but we still have less resources than GHC and are bound to lag behind, it seems. On the other side, there has been some work recently (by Alan Zimmerman, in particular) to improve GHC’s AST and catch up with HSE on that front. So, even if I decide to invest in compilers or dev tools in the future, I’m probably going to team up with GHC instead.

What’s going to happen to these projects I’m leaving behind? I’m less worried about haskell-src-exts. Peter Jonsson has been doing some great work on it, and I hope he’ll step in. There’s also Niklas Broberg and all the wonderful contributors.

I’m more worried about haskell-names, haskell-packages, ariadne. If you are willing to take over any of them, let me know (and you can count on my help). Otherwise, I’m going to provide very basic support for them, but nothing more.

Oh, and in case you missed the announcement, I’m dropping support for my test-framework packages, too.

On the other hand (and to end with something positive), I have no intention to stop maintaining tasty in the foreseeable future. Haskell needs at least one decent testing framework, after all! :-) By the way, here’s a cool use case for tasty that Lars Hupel shared for the upcoming edition of HCAR:

Technische Universität München uses Tasty to assess homework submitted for the introductory functional programming course, which is compulsory for second-year Bachelor’s students in computer science. Students can upload their source code to a web application, which compiles them and executes tests (mostly QuickCheck). Graphical reports are generated with ‘tasty-html’ and presented to the students. Grading happens automatically with a custom test reporter, which – roughly speaking – checks that a minimum number of significant tests have passed. This is a huge improvement over the past years, where tests were run by a homegrown framework which offered only textual output. Tasty however is nicely extensible and allows for easy customization to the instructors’ and students’ needs.