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
- Lack of expertise in Haskell at the company
- Limitations in the ecosystem, such as missing libraries for a
- Providing commercial support, such as high-availability hosted
solutions and on-call engineers to provide answers and fix
- Provide tooling as needed by commercial users
You can already see quite a bit of what we've done, for
- 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:
- We start off gathering requirements from companies- both those
that are and are not our customers- to understand needs
- We create a product in a closed-source environment
- Iterate with our customers on the new product to make sure it
addresses all of their needs
- After the product reaches a certain point of stability (a very
subjective call), we decide to release it to the community, which
- Polishing it
- Discussing with relevant members/leaders in the community
- 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
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
- 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.)
- 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.
- 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.
Do you like this blog post and need help with DevOps, Rust or functional programming? Contact us.