FP Complete’s software pipeline

FP Complete’s mission is easily expressed: increase the commercial adoption of Haskell. We firmly believe that- in many domains- Haskell is the best way to write high quality, robust, performant code in a productive (read: fast-to-market) way. Those of you who, like me, are members of the Haskell community are probably using Haskell because you believe the same thing, and believe- like us- that we can make the world a better place by getting more software to be written in Haskell.

There are two interesting groups that I’ve spelled out in that paragraph: commercial users of Haskell, and the Haskell community. I want to clarify how our software development process interacts with these two groups, in part to more fully answer a question from Reddit.

The Haskell community has created, and continues to create, amazing software. As a company, our main objective is to help other companies find this software, understand its value, and knock down any hurdles to adoption that they may have. These hurdles include:

• Lack of expertise in Haskell at the company
• Limitations in the ecosystem, such as missing libraries for a particular domain
• Providing commercial support, such as high-availability hosted solutions and on-call engineers to provide answers and fix problems
• Provide tooling as needed by commercial users

You can already see quite a bit of what we’ve done, for example:

• Create FP Haskell Center, which addressed requests from companies to provide a low-barrier-to-entry Haskell development environment for non-Haskell experts
• Put together School of Haskell to enable interactive documentation to help both new Haskellers, and those looking to improve their skills
• Start the LTS Haskell project as a commercial-grade Haskell package set, based on our previous work with FP Haskell Center libraries and Stackage
• Provide Stackage Server as a high-availability means of hosting package sets, both official (like Stackage) and unofficial (like experimental package releases)

There’s something all of these have in common, which demonstrates what our software pipeline looks like:

1. We start off gathering requirements from companies- both those that are and are not our customers- to understand needs
2. We create a product in a closed-source environment
3. Iterate with our customers on the new product to make sure it addresses all of their needs
4. After the product reaches a certain point of stability (a very subjective call), we decide to release it to the community, which involves:
   1. Polishing it
   2. Discussing with relevant members/leaders in the community
   3. Making it officially available

Not every product we work on goes through all of these steps. For example, we might decide that the product is too specialized to be generally useful. That’s why we sometimes hold our cards a bit close to our chest: we don’t want to talk about every new idea we have, because we know some of them may be duds.

Some people may ask why we go through that fourth step I listed above. After all, taking a product from “it works well for individual companies with ongoing support from us” to “it’s a generally viable product for commercial and non-commercial users” is an arduous process, and doesn’t directly make us any money. The answer is simple, and I already alluded to it above: the great value in Haskell comes from the wonderful work the community does. If we’re to succeed in our mission of getting Haskell to improve software development in general, we need all the help we can get.

So that’s our strategy. You’re going to continue seeing new products released from us as we perfect them with our customers. We want to find every way we can to help the community succeed even more. I’m also making a small tweak to our strategy today: I want to be more open with the community about this process. While not everything we do should be broadcast to the world (because, like I said, some things may be duds), I can share some of our directions earlier than I have previously.

So let me lay out some of the directions we’re working on now:

1. Better build tools. LTS Haskell is a huge step in that direction, providing a sane development environment. But there’s still quite a bit of a manual process involved. We want to automate this even more. (And to directly answer hastor’s question on Reddit: yes, we’re going to release a Docker image.)
2. Better code inspection. We’ve developed a lot of functionality as part of FP Haskell Center to inspect type signature, identifier locations, usage, etc. We want to unlock that power and make it available outside of FP Haskell Center as well.
3. In a completely different direction: we’re working on more powerful distributed computing capabilities. This is still early stage, so I can’t say much more yet.

Outside of products themselves, we want to get other companies on board with our goal of increased Haskell adoption as well. We believe many companies using Haskell today, and even more so companies considering making the jump, have a huge amount of ideas to add to the mix. We’re still ironing out the details of what that will look like, but expect to hear some more from us in the next few months about this.

And I’m giving you all a commitment: expect to see much more transparency about what we’re doing. I intend to be sharing things with the community as we go along. Chris Done and Mathieu Boespflug will be part of this effort as well. If you have questions, ask. We want to do all we can to make the community thrive.

Subscribe to our blog via email

Email subscriptions come from our Atom feed and are handled by Blogtrottr. You will only receive notifications of blog posts, and can unsubscribe any time.