To follow up the September Update post, which was focused on what we have been doing, in this post I talked about what we will be doing.
5 Likes
I tried to comment on Medium, but I found that there are problems with visibility (nested comments are not always seen), so I put my questions here. Hopefully @myShoggoth will spot this comment. To be extra clear, this is a comment to the post «Into the Future» on Haskell Foundation medium.
How I see the post.
I like this write-up.
- It identifies both the target audience (junior professional Haskell programmers) and the functionality that should be delivered to them (tooling for interactive coding). Let us call this pair of criteria «business model» for short.
- It also tries to answer why by stating the mission (to amplify Haskell’s impact on humanity).
- What I like the most is that it is low in sweet nonsense and high in bitter truth.
That said, it does leave some of the questions it raises or touches upon without an answer.
The choice of a business model.
Even though this is a fine conceptual story, I find that the leap from the mission statement to the business model is one of faith. It is not that I doubt it or think that it will not work. What I am saying is merely that I do not see you deriving the business model from the mission statement, even though you hint at it:
For our first major strategy we looked to generate positive feedback loops. Not only do we want to amplify Haskell’s impact on humanity, but we want to improve our community’s ability to make changes that do the same.
Plastic flower sculpture in a lake.
This focus translates into a bias for accepting Haskell Foundation Tech Proposals (HFTPs) that relate to tooling enhancements that make junior, professional Haskellers, more productive.
The plastic flower sculpture in a lake does not quite cut it.
What other business models have you considered? How did you estimate which one is the most effective?
Measuring the positive feedback loop.
The linking concept seems to be that of a «positive feedback loop». This sounds like you have a quantitative model. There is some quantity that affects the production of itself. Can you name this quantity? How can it be observed?
For example, we can look at the number of subscribers to the Haskell subreddit as a proxy for the quantity of junior Haskell professionals. From the data I managed to dig up, over the last year:
- /r/haskell has grown by 14%.
- /r/rust has grown by 35%.
- /r/AskReddit has grown by 12%.
I am going to take /r/AskReddit as a proxy for the growth of Reddit as a whole for now. Then the growth of Reddit as a whole explains away most of the growth of the Haskell subreddit. What remains?
- The amount of junior Haskell professionals grows at 2% per year.
- The amount of junior Rust professionals grows at 23% per year.
Is it fair to say that the efforts of the Haskell foundation should translate to a change in these numbers? Rust sets a bench mark of possible growth — how closely do we need to approach it in order to consider the business model to have worked?
Surely you have a better collection of indicators than what I have put together on a napkin over a breakfast. Can you share it?
Hermeneutics of suspicion.
The Haskell community is that of idealists. But the money does not come from the community — it comes from companies — that is, from the managements of companies. It is reasonable to suspect that there are strings attached.
What do the managements want? Do they want to scale? Do they need more workforce in order to scale? Is their support conditional on your bringing in more workforce? What are the indicators they will apply to judge if their investment into the Haskell Foundation pays off? (Surely not Reddit statistics!) Do all the managements want the same, or is there dissent among them?
In order for a company to invest money into the Haskell Foundation, they must foresee a return on investment. This should furnish us with an answer to the question I posed in the previous section. How much should the community grow by in order for the managements to perceive a big enough return on their investments?
Have you arrived at the business model independently or has it been given to you by the managements as a condition of funding?
I realize that this is an uncomfortable question. It is unfortunate that it has to be posed. I do not mean to hurt anyone. But I have to consider that there are actors that act in their own monetary self-interest, given how we are all embedded in a free market economy.
4 Likes
Thank you for the detailed feedback!
Strategy
Our Mission is the overarching reason for the existence of the Haskell Foundation, and the Strategy is our first, focused effort to help achieve that. There are many strategies we could choose, this is the one we felt was best in line with the state the Haskell community is in right now.
Haskell, like other open source communities, depends on volunteer effort to make progress. The time and inclination people have are limited, so increasing the overall capacity of our community for improving tools and libraries depends on either making the existing community members more productive, or increasing the size of the community.
We decided that the former made more sense to start with. The latter will be a great strategy once our ecosystem is in better shape to onboard new people and keep them.
Measuring
This is an area we’ve been struggling with, honestly. I’ve been talking with a member of the Rust community and he pointed me at the Optopodi project, which uses GitHub APIs to get information about Rust usage. We are also looking at supporting the State of Haskell Survey to make sure that continues over time.
This is all by way of saying that we’re working on the metrics / indicators issue, and I really appreciate your input.
Sponsor Relationship
The last points are asking how we separate our decision making from the desires of the sponsors that pay our bills, and this is a really important question. If we are too beholden to the companies, the community will rightfully ignore us and go about its business. If we go against the sponsor’s interests completely, they will stop funding us. How do we find a balance?
No sponsor that we have to date has communicated any agenda to me other than wanting:
- A strong and growing Haskell community.
- Support for GHC and the tools and libraries around it.
- An entity that looks out for the entire ecosystem, rather than just one specific part.
If a company has wanted something more specific, they often either work with one of the major Haskell consultancies to make changes directly in GHC, for instance, or directly hire someone who works in that codebase. This is often how companies interface with open source projects that are critical to their business.
So I think we have a deep alignment with our sponsoring companies and the greater Haskell community, but the question is what would happen if there was a disagreement? There we look at our Mission and our current Strategy, plus the resources we have available, and make judgement calls. When those are contentious, the Haskell Foundation Board of Directors will need to get involved and make the call.
I believe we have a consensus in the HF that we value the open source ethos that is the backbone of our community and would rather lose a sponsor than compromise those principles.
5 Likes
Thanks Andrew. Good to hear that our backers are solid.
So, imagine that you had a data scientist in staff. What imaginable metrics would you request to look at, and how would you quantitatively define whether the «strategy №1» is on the way to success or failure in terms of these metrics?
Who knows, maybe someone among the audience will even be inspired to furnish us with these metrics.
Another thing on my mind is that the quantity of junior professional Haskell programmers is limited by factors this strategy does not address. According to this comment, there are no places for junior Haskell programmers to work at. Whatever anecdotal evidence I have on my mind strongly confirms this claim.
So, increasing the productivity of junior professional Haskell programmers is like optimizing a function that is not the bottleneck. It is surely going to also increase the productivity of junior non-professional Haskell programmers, which is good. But still I think the question is warranted.
The obvious solution is to optimize for the creation of new workplaces. For example, by the creation of complete library packages for new and promising fields. Can we, say, commit to rolling out a strong and useful statistics and machine learning library suite? Winning as little as a 1% cut in this market over R would be huge for Haskell because of how relatively small we are. This even sounds like a start-up idea, so maybe we can wield some standard start-up tools to better select a niche where a library can cut a market share, and then execute.
Of course, like any venture capital investment, this is high risk. Maybe there are other ways to increase demand. It is not lost on me that making Haskell programmers more effective will make more companies consider Haskell as a solution to their problems — but it is an indirect way so it is even harder to measure than the effectiveness of the current strategy. The return of an investment into a library is easy to measure.
Summary:
- What if junior professional Haskell programmers cannot appear because there are no workplaces?
- Maybe we should instead focus on creating demand for junior professional Haskell programmers?
- Can we do this by cutting a slice of a big pie?
2 Likes
Dream metrics:
- How many companies are using Haskell for production / line of business?
- How many developers who use Haskell on a regular basis do those companies employ?
- How many people use Haskell regularly outside of paid work?
- What causes people who are actively trying to learn Haskell to stop?
- How many active participants in Haskell communities are there?
I’m sure there are many more, I have notes with a variety, but that’s the core info I’d love to have.
I think that part of the reason hiring junior Haskellers is not more popular is exactly the difficulties in bringing them up to productivity.
I like the idea of packages for new and promising fields, I have thought about that exact thing. I generally think that we need our tools to get better before we can take advantage of that strategy, though, which is why we picked the one we did first.
Addressing chicken and egg problems like this often mean picking one and going with it for a while, then switching to the other side of the problem. I think that’s likely what we’ll do.
But do you think that’s due to tooling? IMO, tooling will make intermediate and advanced Haskellers more productive. Juniors struggle with understanding the language, its pitfalls and type level magic (something that will get a lot worse with linear types and dependent types, btw), no matter how good the tooling is.
The natural instinct is to say we need better documentation and learning resources. But those have never helped me much personally. Only trying stuff out and getting stuck with problems and questions has. And that needs time and effort. Or a good mentor. And mentoring juniors is expensive… it means at least one of your senior engineers can’t be productive.
So maybe the real problem is industry expectations, not Haskell? 
1 Like
Your post reads, to me, like a request for better tooling. 
(For clarity: I’m being a little cheeky here, not willfully misinterpreting your post.)
Juniors struggle with understanding the language, its pitfalls and type level magic
Yes! Better tooling (e.g. better opportunities to warn about un-idiomatic code, possibly laziness gotchas, and better error messages) can help mitigate these challenges.
Only trying stuff out and getting stuck with problems and questions has.
Yes! And better tooling can make this approach work better. Tooling isn’t the only answer, but I do think it’s an accelerant here.
I absolutely agree that no one answer is going to magically fix everything, we’re going to work on a variety of approaches and the whole of it is what will make progress.
One of the reasons I’m so interested in the focus on junior Haskellers is that it makes it clear we’re talking about more productivity with the core language (at most -XHaskell2021), not advanced type features that a relatively smaller subset of developers need to use in anger.
What if we had a mode that HLS could enter that would turn a LHS file into an interactive tutorial, based on the text of the file? Not just having the user read and try stuff, but the editor environment itself gives contextual clues and prompts? Game designers realized a while back that if you teach people how to play the game they’re more likely to enjoy it and stick with it for longer, can we do something like that but for learning Haskell? How about for a particular Haskell library, which could include an interactive tutorial?
And one of the cool side effects of this kind of setup would be mentoring people for these tutorials becomes a lot less of a guessing game: you know what part they’re at, what they’re stuck on, and as you help them through it you could also edit the tutorial itself to help others through the same issues.
2 Likes