Insights

Insights

Insights

Jan 13, 2015

FP Complete's software pipeline

FP Complete's software pipeline

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.