One of the key things about open source development, especially for less business orientated software, is that it’s being written by developers giving up their own free time and free to pick and choose to a large extent what they work on.

This of course means you can’t really use traditional agile software development task management practices, as while key project members might give an indication of their time availability over the next time period, they certainly can’t be held directly responsible to deliver features in a sprint!

So the question is - how can you influence the project to move in a certain direction? Even if you are the original author, you can’t dictate that people work on certain features.

What you can do however is what I like to think of as “soft influence”. This is about what you do personally that makes it more likely that other contributors are interested in and more likely to work on areas that you would like them to.

For example, if there is a cool new feature that could be developed, but there is some tech debt or less sexy bit of groundwork needed to unlock this, just get that sorted yourself. Fix that problem, unblock work in this area. You don’t necessarily need to tell the team what you are unlocking or working towards. It’s not about “I’m doing this, so someone else should pick up and do that”.

Done well, fellow contributors will come up with ideas in the area you are working on/towards, as they are their own and are much more likely to feel motivated about being shafted l asked to work on a particular area

By enabling contributors to start experimenting with something, that can have a positive impact on the project, you make it much more likely they will work in this area. Create a safe space for their creativity or just start the ball rolling on a certain theme. You can never say “I’ve done X, now I expect you to Y”, you just use soft influence to make it suddenly massively more likely they will want to do Y.

Each contributor to an open source project brings a unique perspective and set of skills and interests. When we create systems that are easy to understand and extend, you maximise the opportunity for someone else to come forward with a contribution that moves the project forward. This is especially important when it comes to contribution outside of the core development team. Software architecture really matters here, when you have clear boundaries of responsibility in your code with proper encapsulation, then it makes it easier for these contributors to make incremental improvements, without needing to understand all of the system.

To give an example, I saw that developers were being quite limited when trying to create a 2D effect as pre-built matrix were limited in size or costly and/or cumbersome to work with on the bench. So I added support for Hub75 video wall panels, which are a really affordable option to get higher resolution 2D matrix setup, while still sitting nicely on your desk and not something potentially needing over a square meter of space, especially for things like LED curtains.

By doing this groundwork, others have been able to improve my initial implementation, optimised parts of the system and effects to better support higher pixel counts for any system, as well as providing a cheap way to showcase the Particle System effects, before committing more time, money and space required for a traditional addressable led matrix setup.