Why open-source timelines/roadmaps don't work

In my time working on Julia, I’ve seen a lot of requests for estimates of when some feature will be finished, or a roadmap for how it’s going to be accomplished. This post is intended to summarize why satisfying these requests is sometimes difficult or impossible, and address the much smaller issue of how such requests can occasionally come across as seeming entitled or ungrateful. Over time I’ve tried answering these requests in different ways, trying out different approaches for making the point clear. I should also say that when I started with Julia, I too had some of the same hopes that development would be predictable; you can think of this as a note from my older, wiser self to a less-experienced me.

In my view, the difficulties in providing a timeline (or even a sketch of the solution) basically boil down to two factors:

  • for a nontrivial project, the engineering challenges often cannot be fully anticipated, even in order-of-magnitude
  • the realities of open-source development mean that human timelines may trigger large gaps in calendar timeline

The difficulties of anticipating engineering challenges

Julia has many unique characteristics, not shared by any other programming language I know. (I don’t doubt this also applies to many other languages and open-source ecosystems, but I know Julia better so I’ll phrase this discussion in terms of what I know.) What this means is that implementing new features is often a research project in and of itself. Just because some other languages do X does not mean that all we need to do is copy their solution for X into Julia: often the fact that Julia also supports Y means that prior approaches taken to implement X won’t work in Julia. In such cases, we have to invent a novel approach.

Many of us are used to research being unpredictable. Few would expect a useful prediction of when nuclear fusion will become cost-effective, or when you’ll be able to take a pill to cure Alzheimer’s disease. But it’s easier to imagine that things are somehow more predictable in the world of software. Sometimes, this is even true. But “nontrivial” (whatever that means) changes often seem to fall into a different category. A spectacular example of this was the difficulty in forecasting what would be “easy” and “hard” in artificial intelligence: if I know my history (and I may not), it was thought that playing chess would be hard but navigating a room would be (literal) childsplay—it’s incredibly easy to take some things for granted that one shouldn’t.

In developing Julia itself, there are several factors that increase the difficulty of making accurate predictions:

  • One of the easiest to overlook is the requirement of backwards-compatibility. You might want to add some new language feature, and that might improve the lives of 98% of developers, but what if it breaks one out of every 5000 packages? This is not hypothetical, and the Julia ecosystem has set up PkgEval precisely to test this. There are many examples I could name: two recent ones I’ve seen with varying degrees of closeness are the need to create an API to support foreign objects in order to deliver precompilation without breaking some amazing existing packages and the heroic challenges in instantiating a major upgrade in Julia’s parsing. Often, avoiding breaking even a tiny fraction of packages can add weeks, months, or even years to a project.

  • Some problems are only solvable with tradeoffs. For example, type-inference is always up against the halting problem; you might pay for extra quality of compiled code with longer (or even, never-terminating) compilation. More generally, it’s very common that a cool new capability gets developed, but at least initially the tradeoffs prove to be unacceptable. At that point, it becomes your research problem to figure out how to mitigate those tradeoffs while preserving the advantages of your new capability. Sometimes, heroes swoop in and save the day; for example, the recent advances in precompilation are satisfying in no small measure because folks like @kristoffer.carlsson and @ianshmean made extensive changes to Pkg to reduce excessive precompilation. But as often as not, the original developer(s) usually end up fixing the negative consequences, and because that’s often a completely different problem it’s very unpredictable how long that will take.

  • Some projects are effectively unpredictable developments bottlenecked on other unpredictable developments: there will be lots of cool things we can do with debuggers, Revise, and displaying inference results to users if major changes to Julia’s internals get made, but those changes are research projects of their own.

What this means is that it’s often not possible to predict either how or when a given feature may be finished. It may be possible to put out a “sketch” of a solution, but with growing experience I seem to be getting more reluctant to put those out there. I’ve seen my sketches fail miserably too many times, and putting something like that out in the wild starts making things feel like a contract or setting up some eager volunteer (who sweetly decides to start working based off your sketch) for more trouble than they bargained for.

The mismatches between human timelines and the calendar

Expertise among Julia contributors is not distributed uniformly, and even people who have done amazing things in one subsystem may know little about another; when a project ends up involving an unexpected interaction with another subsystem, now you have a time/expertise problem on your hands. Sometimes someone with the required expertise can guide you through the challenges, but this often requires a pretty massive donation of effort on their part (they have to come up to speed on what you’ve done, and how they can help). Even when the spirit is willing, there may be practical factors that make it impossible.

The other factor is that a small “miss” on finishing something can translate into a large calendar delay. This wouldn’t happen as often if more people were paid to work on (your) hard problem in Julia full-time, but the reality is that many of the amazing changes to Julia are contributed by volunteers: grad students who get fed up with waiting for something they want and just decide to implement it themselves, professional developers whose paying job fully occupies their time on customer-satisfying goals but who decide to devote part of their winter break to work on something they’ve long wanted, etc. But this reliance on donated effort introduces a challenge: when the feature takes longer than anticipated, that graduate student may need to task-switch to prepare to present at a conference, or that paid developer’s winter break may be over, or that grant deadline suddenly looks uncomfortably close and the whole lab needs to focus. Thus, missing by a week of human effort can translate into a month or a year of calendar time: when relying on volunteer time, you can’t even get the order of magnitude right.

Entitlement/lack of gratitude

This is not a big deal, but asking for timelines or roadmaps can sometimes feel a bit entitled: usually the requester is not actually proposing to work on it themselves, which begs the question of why this information is needed. Software development doesn’t need to be a spectator sport where by cheering on new advances you hope to beat the competition. Like other people, I’d love to know whether it’s worth upgrading my phone now or wait for some new cool technology, but in the end the risk for that choice has to be on me.

While it is perhaps just a personal mis-impression, I also think there tends to be an uptick in these kinds of requests shortly after some significant advance has occurred—people naturally get excited to see change, dream big (“here’s what Julia needs to take over the world!”), and start getting impatient. Totally natural and understandable. But if someone walks up to you on the street and gives you a present, few of us would say “Thanks! When do I get the next one?” The better question to ask is, “wow, that made my life better. How can I use this to return the favor by ‘passing it on’ to others?”

Again, this last point is not a big deal. Gratitude in this community is expressed frequently and runs deep. Lots and lots of people indeed “pass it on” by using Julia to write amazing software that attracts new users to the community. I hope it always stays that way!


Thanks Tim. Personally, I’ve been ruminating over why there seems to be such a hunger for timelines and roadmaps for Julia-related development, especially around the core language. What follows is a hypothesis for one possible factor.

For most new features and major advances in Julia development, status updates happen in three places: when they are conceived in an issue or PR, as part of the ongoing commit messages/technical discussion on GitHub/Slack, and in a nice release blogpost after they’ve landed in a tagged version. This seems reasonable enough, but it means that there is not too much signal for all but the most in-the-weeds observers between inception and completion. Given the aforementioned inherent unpredictability of timelines in open source, this perhaps gives the (mistaken) impression that features are announced, go dormant for however long and then magically appear at some random point in the future.

But surely other languages must have this problem too? Most definitely, but it is also worth exploring what approaches they have taken to fill this “missing middle” of status updates. Devblog culture is a great example, whether it be new and updated design ideas or occasional summaries of WIP and accomplishments. Julia’s blogging scene is great (check out JuliaBloggers!) and contains some rich, in-depth posts on language + internals stuff (check out the Julialang blog and https://aviatesk.github.io/posts, among others), but I’ve only seen this semi-regular devblog trend take hold in scattered parts of the library ecosystem.

Another thing other languages have done well is centralizing proposals and discussions on new features in an obvious, well publicized place. Regardless of whether they’re called RFCs, evolution proposals or something else, it’s far easier to get a one-stop-shop view of status updates, outstanding design questions and implementation snags. Though this might not help with getting features landed any faster, it provides more information from which users can draw their own estimates instead of repeatedly bugging maintainers with the same question. On this front, I’m cautiously optimistic about the return of Juleps, as recently mentioned in Discussion on the future for performant programming in Julia - #4 by ChrisRackauckas and implemented in buffer.md · GitHub.


I think it is. It may be the main reason for FOSS developer burnout. We should not trivialize it, but create a culture in the Julia community that discourages this kind of behavior.

Thanks for writing this up. While most of this is known to people who have worked on large-scale FOSS projects, it is practically unknown to everyone else. In a lot of FOSS projects, I have seen devs announcing a big improvement they have been working on for months, to be asked if they now have time to finally fix some other issue, and then get harangued about some trivial bugs that the change introduced. This is not rampant in the Julia community, but the less we see of it the better.


Thanks for the very insightful post, Tim.

I am constantly amazed by the amount of progress that the Julia team is able to bring with limited resources and I might have been one of the people asking for a roadmap.

This was not to have some sort of “deadline”, but to for example see if there’s any area that I could contribute to. One example that comes to mind is tooling: I have the impression that there’s just a couple developers that can spend time refining it and I would like to maybe help, but I don’t know where to even start.

It could be that all the low-hanging fruit is already picked and there’s nothing I could help with anyway. But there are also sometimes threads where interesting discussions about features happen, and these discussions seem sometimes a bit disconnected from the project itself.

I guess what I am trying to say is that having some sort of roadmap could help with better identifying gaps, prioritising, geting some community support, etc…

On the other hand, I have no experience running open-source development project and organising this sounds like a lot of work already, so perhaps I am just being very naïve about this helping :person_shrugging:


We love core team! 1.9 is truly fantastic. Not many pieces of software improve at this rate, even with Googly money. We love the hard work, great releases, and the flow state feeling of using Julia.

I imagine the psychological toll is pretty high, managing expectations of a rabid fanbase. Please take care of yourselves and focus on what’s important to you.


@tim.holy , This is a great writing.
Clear and able to coney the message.

This tension exist everywhere, not only in FOSS development.
The only way working it out is by communicating well, like you did here.

I would like to hear your opinion on a slightly different angle.
If we replace the question of when with what, what’s is being worked on.
I think this small change will make communication easier.

The main gap is what are the goals and what is being worked on.
This gap doesn’t exist for the group of core developers, as the answer is in the PR’s and Issues.

To bridge the gap, we need to create a simple communication paths.
A timely forum post or a blog post will do wonders. It will benefit all sides: The developers will feel the warmth of the community which they deserve for their work, which is amazing, and the community will have its curiosity satisfied.
The curiosity means people care, and the caring of the community is the fuel, to some degree, of FOSS.

I will give an example, I still remember the dots blog post.
It was perfect, it showed the vision. No need to say when, just what’s the aim.

I’d quote a great sentence in my opinion: Plans are useless, but planning is indispensable. (Dwight D. Eisenhower).


Formalization of Juleps would help. I try to assume everyone has good intentions no matter the perceived tone of a discussion. However, this is the internet and any amount of social anxiety or defensiveness make it hard for people to interact in a productive manner. Adding structure helps resolve a lot of this.

Its worth mentioning that the Julia community works very hard to maintain a positive attitude. It’s not perfect but even boneheaded mistakes I make haven’t completely gotten me banished from Julia involvement. So I hope new comers coming across this keep that intent on positive growth in mind.


One then must wonder: is it worth it? When presumably fixing the packages might be just a fraction of this additional development time?


One might consider finishing unfinished packages or features. It is harder in practice due to the expertise involved and familiarity with the code, as well as communication with the original dev in general. Hopefully, their efforts just don’t get wasted and abandoned as people just develop another package. One step might be to encourage people to announce things in progress. Having experts onboard that could help you when things go wrong can be a big help.

Well, I do believe the response is positive in general. It is like “Cool, and you got the next ones planned right? That’s awesome!”

Julia was founded on greed. We wished for it to be fast, easy, etc… naturally, people would wish to do things done in other languages even though we have less than 1/10th the resource those languages have. We’re greedy. We want to do it in the best way possible, even when it means the most difficult way. We wish we could have the problems magically go away, but each feature of the greedy Julians is painstakingly implemented by talented Julia developers. We’ve done quite a great job, yet there are more. But as we demand the language, the language demands back. Yes, while it’s true Julia was designed to not take many devs, many tasks require expertise few would possess. We demanded the language to be fast, but while simple loops/etc may be, there is still a subtle price to be paid in a high-level language. Abstraction means abstracting details and doing away with fine-grained controls and while we may set up things right, there are some more fine-grained details like memory models/ pointer-value hybrid/ etc which are still to be worked on. We may preserve the performance but not always the subtle, fine-grained issues that are needed to implement high-performance algorithms/data structures. These issues will be dealt with but with even more expertise.

Yet, we still move forward, no matter what hardship lies ahead. Many contributors in the Julia community are one-man armies. I’m grateful for Julia, and I wish them success in what they do.

Still, what it means is that we need more experts!

1 Like

Oops, I think I am in this camp as well, as I think I mentioned that having a roadmap would be nice in the mojo thread. I definitively meat “roadmap” and not “timeline”, as something I was used to in other languages is reading proposals and new versions of standards well before they are implemented, and I didn’t find anything equivalent in Julia.

For example, in C++ we know “modules” and “concepts” will become widely available at some point in the future (being quite experimental for the moment, but endorsed by the committee), or in Fortran we knew since 2008 that a post-MPI approach to distributed computing was a WIP (coarrays, which took almost a decade to implement in open source compilers). Btw, we also know that the Fortran committee rejected a series of interesting proposals…

I think I meant something like that, that I would like to read more things like the aformentioned Chris’ response where he shares a list of priorities, or proposals like buffer.md, etc.

I also want to second @Amval, if proposals like those are shared and discussed, more people willing to contribute to Julia can perhaps point their efforts towards the issues that could have the largest impact, or at least, avoid toying around with experimental packages that are more likely to become discontinued.

Of course, in open source, the more talented people with the more relevent skillsets will be making the largest contributions, and others will simple contribute some of the testing, bug reports, help out with documentation, etc.

As for some of the improvements being hard research topics on their own, that’s actually interesting, as some of us are full-time researchers, and while we might not be doing research in compilers, in some cases we have a certain degree of freedom in choosing research topics… so if someone shared their view of “how we should improve escape analysis and shape inference to aid with allocation-optimization passes… note that this is hard and a research topic, we would first need to solve X and Y” well, they might have just gained some potential collaborator :wink:


It’s totally not as if roadmaps don’t exist in Julia in general, JuliaImages has one: JuliaImages 1.0 and beyond — a two year roadmap · Issue #977 · JuliaImages/Images.jl · GitHub written by @JohnnyChen94 albeit progressing towards it and it fully working n on time is a completely different question


Note that the “we” in this context is the developers, ie people who actually contribute (mainly code, but also issues, doc fixes, tooling, etc).

The funny thing is that once someone becomes part of this “we”, they rarely ever ask for timelines, because they are doing (part of) the work themselves.


I tend to think it is worth it - there is not only package code, but tons of unregistered code in the wild. So packages failing some tests are just a canary for more code which might have similar problems. This may also concern examples in discourse, stackoverflow etc.


For me it is one of the important plus Julia has (in this case the development of Julia).

I have some other tools and languages in use, where it’s the opposite: Development is seen as much more importance as not to break anything. I see the arguments which speak for it, but in daily life it’s a major annoyance. The result is, that I hesitate to update, which is a problem on it’s own.

Of course it happens in Julia too, that something breaks, but it just has a much lower frequency and (until now) a much better quality, means I never had any big problems with anything breaking. This encourages me to do updates anytime I feel it’s time for it (which is often).


It might be possible to collect these sample codes in the wild and add them to the PkgEval system.

I guess we could start by including papers with julia code.

That won’t work for private packages. Julia’s stability guarantees mean we have to keep those running, too.

One reminder: if a package fails its tests, it ends up not getting “counted”—we only pay close attention to regressions, where a package passes on the previous version of Julia but fails on the development branch. Making sure your package passes its tests reliably is a good way to make sure things you care about are tested.


These are great roles for community participation! One of you could start a “this week in Julia development” newsletter, where you monitor Julia’s GitHub and then write things up in an manner that can be understood by a wider audience. That way it doesn’t slow down developers and word gets out about the cool happenings in Julia development.


That sounds like a great idea, but I would just push back gently on the notion that writing about what one is doing once in a while “slows down” developers unnecessarily. Posts like How Swift Achieved Dynamic Linking Where Rust Couldn't - Faultlore can only be written effectively by those who were in the trenches doing the actual work, so the sole burden should not be on third parties to cover all development-related news.

And to pre-empt the question of “won’t this bring more work for already busy developers on Core/Base?”, I don’t think the impact will be significant because such writing already happens. It’s just scattered across myriad PR threads, issue comments, gists, HackMD documents, Google Docs, Slack conversations, etc. In short, not great places for reading and only places you’d find by regularly browsing the issue tracker.

It’s difficult to say what would incentivize writing about those in a more accessible and obvious place, but showing the level of interest in such writing could be a start. If that works, it would then be easier to identify gaps in cool new features not being written about—I’ve seen a few instances where some development in e.g. const-prop is hailed as a big deal :tm:, but when one tries to look further all that can be found is a lonely set of PRs with very short descriptions and equally concise review comments!

Just to give my own experience, it does slow me down: the half-dozen or so posts I wrote for the JuliaLang blog each represented between a day and a week of effort. This was despite the fact that indeed I had all that material you describe; writing for different audiences takes me, at least, lots of time. GitHub PRs are addressed at knowledgeable developers, blogs at a much wider community where you have to provide much more background.

Have you found a way to blog about your own contributions without it taking a lot of time? If so, what’s your secret?


Looking back at years of experience in various companies and research orgs, this doesn’t jibe at all with my experience. There are often requirements or requests for periodic or occasional progress reports. Everyone dislikes doing them, puts them off, ignores them, finds them burdonsome, etc. Even those for internal consumption are time consuming and at least somewhat emotionally and psychically draining. If it’s for public consumption, the level of organization and polishing expected (much less than professional publication) requires far more time and effort.

This happens for required reports on your main paid work. Asking volunteers whose time is stretched thin why they can’t just please make a little effort and write a report for me, seems presumptuous. If you want something like this, do some work to set up a system to make it easier and then maybe they’ll use it (probably not). Perhaps do an interview collect notes and write it yourself… I don’t know.