Implementing new features for FlightGear: Difference between revisions

That way, contributing becomes pretty much a '''journey''', where you may meet people willing to accompany you for a certain time, task and project, until their own goals have been reached, or they join some effort (or even project). Sometimes this journey make take a few months or even years, but often it's really just a few weeks or even just days that someone finds some of your project overlapping with his own goals and interests, such as for example programming shaders/effects or doing Nasal scripting or helping with [[Canvas]] related projects.

 

In retrospective, this is exactly how some of the most popular base package projects took shape recently, despite a lack of momentum initially: People were willing to compromise their original goals by talking to others who had somewhat overlapping, or at least sufficiently similar, goals and found a way to collaborate to a certain degree, even though every contributor would still keep his own long-term goals and priorities in mind. Sometimes, this requires a significant shift in thinking and creative or very unconventional ways to explore a new solution space.

This is why you'll typically have to reach out other contributors and ask them to get involved. And this is also exactly where most people fail right from the beginning: because they're more focused on their own goals and projects, than demonstrating to fellow contributors, how they can help improve others lives, i.e. by learning more about other projects and efforts, and potentially overlapping areas there.

 

Conceptually, this boils down to thinking in terms of components, i.e. building blocks, that need to be established in order to accomplish something. It is very likely that a dozen unrelated projects may benefit from very similar building blocks - typically, there's at least a handful of needs that projects may have in common.

Note that this doesn't have to do anything with programming, '''building blocks''' can just as well be non-coding items, like textures, sounds, instruments, 3D models etc.

Successful contributors realize that such overlapping areas are an excellent opportunity to get others involved, but also to get involved in other projects, that may not be directly related to their own area of interest - i.e. to learn a new skill, or even just introduce yourself to a contributor with a known track record, to pave the way for future collaboration.

For instance, some of our most active contributors have very little time to provide support to end-users or even just maintain their documentation, this could be a great opportunity to introduce yourself to a contributor - you're demonstrating that you're interested in contributing, while also saving them some time, so that they can work on other projects, so that you inevitably show up on their "radar".  

Still, there may be areas with little, if any, momentum and where networking doesn't seem feasible, this is where you may have to make an upfront investment to get other contributors involved, i.e. reach out to re-implement/replace features or infrastructure with parts of your own work. This is basically a pretty safe way to get more eyeballs involved.