Which existing open source projects would benefit Elixir the most from extra dev effort?

Just for discussion sake, I thought it would be worthwhile to have a discussion to give ideas to community members looking to contribute to open source projects for Elixir. Which projects out there would provide the greatest benefit if they had more contributors?

This is a bit of a weighted question because not every project benefits from just having more people help out and some projects are already getting plenty of attention.


Since nobody is responding yet…I’ll start.

I think Coherence is probably the most in-need.

One of the things constantly celebrated in Rails world is just plugging in Devise (by Platformatec). Coherence is the closest equivalent in the Elixir/Phoenix world. It seems like it’s maintained by a single developer, which is impressive given the number of different options that are out there.

Working issues, adding additional modules to support MFA and webauthin for Yubikey/FIDO, etc would go a long way for the community as a whole since so many projects build around this type of functionality. I’ve thought about building anti-phishing module for it at some point.

What other projects though?


Yes Coherence is really important project. Also Talon, Arc, drab projects need help and i believe really important projects for elixir community. I think we need to build core teams for these projects.


This thread may also be of interest:


I keep wondering the same and I am pretty sure there are plenty of maintainers who would appreciate the help… yet somehow this issue rarely if ever sees any visibility here on ElixirForum. I find it baffling.

The very small number of replies in this thread shows this yet another time.

I am looking to help a project or two with a small workload and as awesome I find Drab, I don’t feel it’s my thing. Will look at Talon and Arc.

Also, this does not exactly help – what about projects who don’t exist yet? Example: I keep pondering trying to write a library that does pretty and efficient data diffing but I am still unsure if that’s actually needed.


Not to get too off track here, but i want to indulge this. One thing i really wish Elixir had from Ruby is Hash diffing.

1 Like

I realize it’s a bit of a case of domain specific knowledge, but Nerves Project could use a bit of help with a few things, one easy thing is documentation. I recently followed the getting-started guide as a test, but i have a working memory of the system since its’s inception a number of years ago, so i don’t get tripped up like a new user might.

The other thing i’m most interested in fixing/working on is nerves_network. I’ve been working on it for a long time, i just don’t have much progress to show unfortunately. If anyone is interested in helping with that particular project, pm me, or reach out to us on slack.

< /plea>


Absolutely Elixir-LS by @JakeBecker. The language server is the backbone of modern tooling for Elixir and there’s still a lot of work to be done here. If there’s going to be strong tooling for Elixir as there is in many other languages, the language server is the place to start.


I agree with that one. I think the biggest impact you could have in elixir is exactly around tooling and editors. There’s a lot of very useful and cool things that could be done.


If we’re talking about things that don’t exist but should, I’d vote for an Elixir implementation of:

The core team isn’t interested in taking Flow in this direction. But it’s an extremely powerful and foundational concept. One that I think would benefit many Elixir projects. The associated ecosystem of high quality processing modules would provide additional benefit to the community.

What do you mean by hash diffing precisely?

1 Like

I just looked more into it. My apologies i thought this was Ruby standard library.

After a thinking about it i don’t think this is a great idea, since it depends heavily on the information it is comparing.

Also i’m sure there’s a hex package for this

This code would be a trivial port, if it meets your needs.

1 Like

I also agree that tooling is a very important part. (although I don’t like my editor doing anything other than editing and syntax highlighting personally.)

Can you sum up the key differences between this and Flow?

Both Akka Streams and Flow promote backpressured async stream processing.

But Flow’s purpose is to behave and provide a DSL to support Map/Reduce and Spark like jobs.

Akka Streams supports more foundational lower level concepts. There are standard components, Source, Sink, Flow, Fan-in, Fan-out, along with a graph based DSL that lets you compose these components together in arbitrary ways, while supporting standard functional transforms like, map, filter, etc over streams.

With a standard component model you can start to build an ecosystem of data processors and connectors. https://developer.lightbend.com/docs/alpakka/current/

If you like GenStage as a component model. Then these would be two DSLs that could sit on top of GenStage, providing a better developer abstraction.

You wouldn’t build the next generation of Phoenix on top of Flow. But you could/should with this new thing.

1 Like

I think it would be great if this project, or similar, got some love and attention

1 Like

I’ve never used this, but i do wish hot code reloading or some framework to implement it was part of Elixir stdlib.

Does anyone know if Phoenix reloader is modular enough to work outside of Phoenix?

Cool. Thanks for the description.

Try ExSync. it’s pretty good. It needs as much help with promoting it as with contributing.