How to get more dev contributions to our FLOSS project

Questions / Help
, , ,
1

Hi, I’m Ivan, co-founder of Bonfire Networks.
In the past 3 years we’ve worked full time building an open source framework for developing modular federated digital spaces.
We adopted Elixir through the whole stack, including Liveview (and Surface) for the Frontend, and we’re excited to experiment with LiveViewNative for building native apps.

Think of Bonfire like Wordpress but for federated social networking. You can setup a home for your community (a digital space) and this can be as simple as a basic microblogging platform (such as Mastodon).
From there, digital space’s maintainers can add and tweak plugins to extend its functionalities.
Such plugins aim to extend the agency of a community over the federated network, going beyond the standard microblogging experience.
This includes convivial activities (such as organizing events), political (such as performing decision making tasks), coordination (assigning tasks and collaborate on projects) and so forth.

We believe this is a crucial objective for communities to move beyond polarization and mainstream centralization and give them agency to self-organize in a federated environment, rather than in a walled garden.

In the past years multiple communities reached out, inspired by such vision, to co-design the features they needed for each specific case studies.
Among them, a lot of scientists / professors / researchers, reached out for experimenting with Bonfire looking for a proper alternative to x / mastodon.
Together we built the https://openscience.network case study.

We (the bonfire team) are now in a situation where we have multiple communities and users that are waiting for the software to be ready to adopt it, but we are struggling with the last 10% of the work needed to be done to properly and safely release the awaited bonfire 1.0.

The software is in beta, we’re dealing with some performance issues both on LiveView and Ecto, bugs, plus help on improving and securing the existing codebase.

We’re currently sustaining ourselves through EU grants and donations, and communities are starting to apply to grants to develop ad-hoc bonfire modules for their specific use cases.

I wonder what is the best way to reach out for help and increase the contributions for our FLOSS project.
It’s something new to me. Coming from an activist background I am more used to get in touch and connect with communties / collectives and end-users, rather than developers.
PS We’re not looking for unpaid work, we really care about creating a sustainable environment where developers can coordinate p2p and work together to experiment and benefit existing communities.

I’d love to get your suggestions and help on how to lower the entry barriers, extend the elixir dev interest and knowledge about the project and in the end get more contributions from the dev communtiy.

10 Likes
2

Glad to see you got in here. Bonfire is very cool, super interesting and I really hope you get some people trying it and helping get it to the users.

It is very unusual to have devs that find both users, money and open software working out at the same time. And you have.

Note: I’ve spoken to the Bonfire crew a few times now so this is not news to me.

If you want to build open stuff for actual users, consider digging in!

2 Likes
3

The key differentiation between Bonfire and Mastodon is that you have a open plugin architecture. I’d suggest to improve the documentation and backward compatibility in that area, so more plugin writers would come. Few people would dive in and fix bug in the Bonfire core out of the blue, but if the bug/performance issue affect their plugins then that’s motivation right there.

1 Like
4

I think that’s just one example of a larger whole. The idea would be working towards a place where developers are able to “use” bondfire and I consider “use” in a rather wide sense here. It’s not just them using bondfire for their intended business tasks. They could use it as a learning tool for a larger but still open source project. They could use it to get involved with other devs around a shared project, where tradeoffs are made not just based on “in theory”. They could become plugin developers, because they actually use bondfire.

Given the project is literally around communication and community I’m sure there are ways to engage with developers in a way that it’s benefitial to all parties.

2 Likes
5

The name’s bondfire…James Bondfire

6 Likes
6

Improving documentation makes total sense, our main blocker atm is that we have issues releasing the core framework. This prevents both communities to start using the basic version of bonfire and therefore asks for more specific features and prevents also developers to build plugins to extend the functionalities, since the DX is not smooth and there’s not that much incentives atm.
We’ve started working on some tutorials for building plugins , some general intro and docs, but they do not cover yet all the moving pieces.

1 Like
7

Yet this sounds like a great way of playing and improving the framework. A kind of “learning by experimenting” space where developers and designers can setup their own digital space and dogfooding by building and using different plugins. I wonder if there are ways to properly communicate and encourage such vision to make it happen…
Another possibility is for different communities to crowdfund specific features of mutual interest. The funds raised could be allocated to developers for implementing these features as standalone Bonfire plugins. But such strategy would be feasible only once the core framework is released, stable, and adopted.
We need to do the last 10% to get there and then encourage such initiatives…

1 Like
8

Really like the idea of the project. I will dig into the documentations you have linked to to see how one can contribute.

Is there a consolidated place to track what you all need help on and their priority?

1 Like
9

we do have several milestones on github, and currently we’re focusing on the 1.0 beta milestone - As you see most of the issues are about bugs or LiveView improvements / fixes and optimisations ( the app is incredibly slow and we didn’t yet exactly figured out why :face_in_clouds: :face_in_clouds:) - you can ty it out on our testing instance - loading the feed takes more than 6-7 seconds :thinking:
Maybe a first step could be create a new milestone with few meta issues that are focused on what is blocking us? Maybe our current milestones may be too intimidating for new devs?

10

My main concern is that initiatives like Bonfire will remain very niche as long as the big corporations still control the main social activity scientists engage in: communication in journals. Therefore, one interesting target audience may be editorial boards: the systems that editorial boards of journals use to communicate, to edit and review manuscripts are not only antiquated, they were already bad when they were new and haven’t improved much.
If a large and well-known enough platform such as, e.g., ORE from the European Commission were to implement something like Bonfire to lure away editorial boards from the parasitic corporations, it may get the snowball rolling.

1 Like
11

Can’t speak for others but I think the list of issues in the 1.0 beta milestone seems good enough for a new contributor to guage where the current priorities lie. It might be hard for you to preemptively group related issues that also match the contributor’s interest and skills.

I setup bonfire locally yesterday. Will review the issues shortly and reach out to you all on your matrix channel to discuss where I can help.

3 Likes
12

I’ve been curious about Bonfire since I came across it last year, and have been looking forward to 1.0. I have some experience with optimisation, and would be happy to help, but may need some guidance as my Elixir/LiveView/Phoenix is still at a hobbyist level.

1 Like
13

happy to support you in getting up to speed :fire:
Getting help on optimisation would be awesome :raised_hands:

14

Bonfire was definitely in my list to review when I compiled a list of open source projects for nonprofits. However I couldn’t quickly get it running locally and found the setup documentation bit difficult to scan through. I am happy to check again with the docs and see if I can get it running locally and can look at some of the open issues. Thanks for your work!

1 Like
15

Generally people contribute to things they think will benefit themselves. Some ways this might happen:

  1. They want to use your product to help further some personal goal of theirs
  2. They think contributing to your project will help build skills they want to reach their own personal goals
  3. They are paid money

For 1 and 2 it is hard because you really have to convince strangers you have something to offer they can’t find easier/better elsewhere. It is easier to do this once you’re established and people hop aboard the hype train.

In my opinion, 3 is your best bet. I don’t see anything on your Github page about money so making that more obvious might help.

2 Likes
16

Sounds great, would love to hear your feedback to improve dev onboarding and docs :fire:

17

I think the decision to use just as the build tool and having the various components be split in different repos that are then pulled in when setting the dev environment, add to the learning curve to get onboarded. I am guessing when things work this wouldn’t be a problem. In my case it didnt work right away and when I started debugging, that’s when I realized how the project is structured in an unusual way compared to other elixir projects.

Maybe a high level overview of the build process and what all happens when one runs the just config or just setup commands could help simplify things :slight_smile:

3 Likes
18

I had the same issue a year or so ago when I was thinking to contribute. I asked around some issues and in the matrix chat but It was really a pain to have it running locally. When I finally was able to run it locally(mostly using docker iirc) there was a pain navigating the internals of the project. I’m not sure if it was the amount of moving pieces or the lack of docs at the time.

I was waiting a full release to try running an instance and try learning the internals of the project to try to contribute again.

1 Like
19

I really like this project i’ve been following it way before the beta, i’ve played around the test server when you people made it public. I hope it grows and become a solid option on fediverse.

1 Like
20

Great feedback, added a new issue Document and explain the internals of the build process and main just command to improve DX · Issue #938 · bonfire-networks/bonfire-app · GitHub

3 Likes