The team will work on the code intelligence infrastructure to be used across tools and editors. These efforts are partially funded by Fly.io and Livebook.
Nice! And thank you to everyone forming this new team!
This actually echoes an idea I’ve had but haven’t had time to properly thrash out/post on the forum yet (think I first hinted about it in that old Brex thread) but essentially I was thinking how smaller, more independent projects like Elixir can compete with those funded by giants, and I felt reimagining how core teams are comprised could be a really nice fit for such projects, where essentially you still have a core team, but you also have smaller highly-specific or specialised teams, eg:
The reason I hadn’t posted about it is because I wasn’t able to give it as much thought as I felt it needed, for instance, when you expand a team, that inevitably comes with additional potential problems (because now you have more people who are ambassadors of the project). This was partly why I felt these teams shouldn’t be clumped in with the ‘main’ Core Team, but rather sub-teams - so there is a clear difference yet you still get a similar feeling of pride for being part of or in an officially recognised or linked team. I think it could be a really nice way for more independent projects to get the kind of support they need, essentially writing their own rules on how to grow in a sustainable way.
Of course there are other considerations too, such as the added responsibility for the core team to then have to manage smaller teams - but my initial feeling was that it would be worth it (just hadn’t had time to think about all the possible pros/cons).
So… personally I am very glad to see José and the core team have been thinking along the same lines, and I wonder whether we’ll see more of this in future
Indeed, managing software and especially innovative one is a very complex thing, it seems that the elixir ecosystem came a long way on how to do this without relying on big corporations.
Looks like there is a huge improvement in regards of funding for this type of work, which is not only exciting, but will most probably change drastically the landscape of elixir tooling and libraries.
I think this is in no insignificant part down to José and his trust in the community. He is involved in a very large number of projects and initiatives, but from what I’ve witnessed is happy to give autonomy to the leaders of those projects, often suggesting things instead of insisting on them.
That’s certainly the experience we’ve had on the forum - when we first set it up I used to run a lot of things by José (in part because I didn’t want him to think we weren’t considering his needs or for him to feel sidelined) but he’d often say things like “Thanks Aston but I trust you - you don’t need to run everything by me”
Not only is that smart in terms of his own time-management, but I think it has a tangible effect on others too, as it makes you want to do even better. I think the same could be true of these sub-teams.
It’s great that we’ve got more funded work and again testament to how Elixir has grown. My idea of sub-teams however was not contingent on funding (especially from tech giants) as there is obviously great value in being part of an official team - not only in terms of personal achievements and goals, but also in ways which could help the person too - as it could open the doorway to becoming an author, speaker, or being more attractive to an employer.
As I mentioned though the two biggest challenges are it means the core team has to manage more people/teams (though I think it would be worth it, especially if you consider how large these teams could become and the value they could add) and obviously that when you become part of an official team then you become an ambassador of the project, so your conduct (and the views you share publicly) will be held to a higher scrutiny and must not bring the project’s name into disrepute. This was the area which I hadn’t had time to give more thought, as it would require a clear framework so that everyone knows where they stand.
Great! I updated the graphic in my post above as I couldn’t find my original graphic/notes so had just quickly put something together for the post. Interestingly, this framework could work even better for projects like Phoenix as there is so much scope for such projects…
I’m not sure what the project’s or the author’s status is, but maybe there’s things in there worth ‘borrowing’ that none of the other plugins have managed to focus on yet.
This is not an effort, this is a great extension that was working extremely well for years before other language servers became as polished as they are currently. The project has a little downtime and lacks support for the newest OTP/elixir releases as the there is a new maintainer, expect for things to improve very soon.
Back in the day, the plugin was almost entirely written in Java, a completely different approach to what elixir-ls and lexical took, so the ideology behind how they aim to work might be completely different. These days I see that there are 30%+ of elixir code, but they might be just tests.