20,741
edits
Implementing new features for FlightGear: Difference between revisions
Jump to navigation
Jump to search
m
Implementing new features for FlightGear (view source)
Revision as of 01:52, 18 May 2014
, 18 May 2014no edit summary
mNo edit summary |
|||
| Line 1: | Line 1: | ||
{{WIP}} | {{WIP}} | ||
We've been seeing an increasing number of discussions on the forum started by people who are obviously eager to become potential contributors, either by adding new features to FlightGear, or by improving other aspects of FlightGear as a whole (community, infrastructure, usability, end-user support, accessibility, funding etc). Unfortunately, this has caused some friction over time, because people were expecting their involvement to work differently, especially those primarily making suggestions and providing feedback through discussions are obviously getting fed up with the community of contributors not responding directly to such feedback. | We've been seeing an increasing number of discussions on the forum started by people who are obviously eager to become potential contributors, either by adding new features to FlightGear, or by improving other aspects of FlightGear as a whole (community, infrastructure, usability, end-user support, accessibility, funding, hardware support, backward compatibility etc). Unfortunately, this has caused some friction over time, because people were expecting their involvement to work differently, especially those primarily making suggestions and providing feedback through discussions are obviously getting fed up with the community of contributors not responding directly to such feedback. | ||
Now, we do appreciate any community involvement obviously, but people who are serious about actually bringing certain changes to FlightGear will find that just making suggestions will typically not work too well, and that just participating in lengthy community discussions is usually fruitless, too. Indeed, as contributors, we would also appreciate it if it would suffice to just make a suggestion and provide feedback. But that's not how things work unfortunately. | Now, we do appreciate any community involvement obviously, even just people making constructive suggestions, but people who are serious about actually bringing certain changes to FlightGear will find that just making suggestions will typically not work too well, and that just participating in lengthy community discussions is usually fruitless, too. Indeed, as contributors, we would also appreciate it if it would suffice to just make a suggestion and provide feedback. But that's not how things work unfortunately. Still, most of us went through this whole process at least once, so we do know pretty well what it felt like, including all the frustration surrounding it, i.e. of having some great idea or vision, and seeing it not recognized as/dealt with as such. | ||
We've had some extremely heated discussions over the years, some debating really interesting ideas and features - and many ending up being dozens of pages in size, containing hundreds of postings. Nobody in their sane mind is going to dig out such old discussions and spend hours to | We've had some extremely heated discussions over the years, some debating really interesting ideas and features - and many ending up being dozens of pages in size, containing hundreds of postings. | ||
Nobody in their sane mind is going to dig out such old discussions and spend hours to find the valuable stuff. But often, even such heated discussions may still contain lots of good ideas and suggestions, but sooner or later these debates become emotional and are no longer constructive - yet, we're dealing with them constantly, which is taking up resources, i.e. time and energy. And even those among us who usually remain levelheaded, may find their valuable postings remain unnoticed in such threads. | |||
In an open source project like FlightGear, which is entirely volunteer driven, time is the most precious resource we have to contribute. It is like a "currency" for the project, and whenever something (or someone) is taking up lots of time without anything materializing, this is draining resources from other areas, no matter if it's end-user support or development in some shape or form. | In an open source project like FlightGear, which is entirely volunteer driven, time is the most precious resource we have to contribute. It is like a "currency" for the project, and whenever something (or someone) is taking up lots of time without anything materializing, this is draining resources from other areas, no matter if it's end-user support or development in some shape or form. Basically, some of us have literally wasted dozens of hours trying to contribute to such discussions in order to provide some direction, to no avail however. | ||
We are now trying to document how "bootstrapping" a feature or project works ''conceptually'', i.e. implementing new features for Flightgear from a high-level standpoint | We are now trying to document how "bootstrapping" a feature or project works ''conceptually'' from having an idea to turning it into a feature, i.e. implementing new features for Flightgear from a high-level standpoint to provide a perspective that enables people to better understand how to bring changes to FlightGear without having to do all the work on their own, and without necessarily having been a part of the community for years (or even decades). It's been shown that this particular model also seems to work for newcomers. | ||
Note that this doesn't mean that this is the only way to accomplish something, but this is a tested and proven way - which | Note that this doesn't mean that this is the only way to accomplish something, but this is a tested and proven way - which nobody really came up with, but which is just a convention that happens to "just work" for all contributors, which is an important aspect for a non-organized project like FlightGear, where development itself also primarily "just happens", so any form of coordination, networking and collaboration must be self-directed, too. | ||
Currently, this article is | Currently, this article is mostly based on a write-up that Thorsten contributed based on having worked on a variety of novel, and unprecedented, FlightGear features over the years which initially also didn't receive much support at all, and which also caused lengthy discussions (or even flame wars) on the forum and the devel list, including features like [[Advanced weather]], [[Atmospheric light scattering]], [[Procedural Texturing]] and most recently the [[FlightGear Newsletter April 2014|EarthView]] orbital rendering engine. None of these were implemented through so called core development, which would typically mean that people change/write C++ code and have to recompile the FlightGear source code. In fact, one could see that all of these changes could be qualified as so called "mods", even though all of them have meanwhile become an official part of the main FlightGear distribution. | ||
These are just a few examples to put some context around the advice given here. Also note that the people who contributed to this particular write-up are not FlightGear core developers per se, we are also primarily middleware/base package contributors, i.e. contribute to those part of FlightGear that are typically considered very "accessible", as you don't need to be a programmer to make a meaningful contribution. | These are just a few examples to put some context around the advice given here. Also note that the people who contributed to this particular write-up are not FlightGear core developers per se, we are also primarily middleware/base package contributors, i.e. contribute to those part of FlightGear that are typically considered very "accessible", as you don't need to be a programmer to make a meaningful contribution. This means that making changes to these parts of FlightGear typically involves editing text files (XML, scripts, effects, shaders) or textures (images), sounds or 3D models. | ||
And when we started out a few years ago (and several thousand postings back), we were also highly critical about [[How the FlightGear project works|the way the project works]], and all its shortcomings. And now, we're often the ones being "yelled" at on the forums when dealing with newcomers, even though that's exactly how we started out. | And when we started out a few years ago (and several thousand forum postings back), we were also highly critical about [[How the FlightGear project works|the way the project works]], and all its obvious shortcomings. And now, we're often the ones being "yelled" at on the forums when dealing with newcomers, even though that's exactly how we started out. | ||
Yet, fast forward 5+ years later, we are still trying to contribute in meaningful ways to the project, despite some (or even many) of these problems still persisting even today. So this is an attempt to provide a '''lessons learnt''' intro based on newcomers | |||
Yet, fast forward 5+ years later, we are still trying to contribute in meaningful ways to the project, despite some (or even many) of these problems still persisting even today. So this is an attempt to provide a '''lessons learnt''' intro based on newcomers becoming contributors, turning their ideas into features that actually end up in FlightGear, without having to be expert programmers necessarily, or even programmers at all, and without having to be familiar with FlightGear. | |||
== What is this about? == | == What is this about? == | ||
| Line 24: | Line 26: | ||
Like many FG users, you probably reach a point when you think 'Wouldn't it be nice if we had feature XY?' From this point, there are various options available: | Like many FG users, you probably reach a point when you think 'Wouldn't it be nice if we had feature XY?' From this point, there are various options available: | ||
* You mention it in the forum: <br/> A vast body of observation suggests that the likely outcome of this is that several users will answer and tell you that it is a good idea, a few long-term contributers will chime in and point out possible difficulties, and it will end there. | * You mention it in the forum: <br/> A vast body of observation suggests that the likely outcome of this is that several users will answer and tell you that it is a good idea, a few long-term contributers will chime in and point out possible difficulties, and it will end there. Some may point you to past discussions to provide a few pointers. | ||
* You make a formal feature request on the issue tracker: <br/> The most likely outcome are a few comments and then the request will be assigned a low priority and not much else will happen. | * You make a formal feature request on the issue tracker: <br/> The most likely outcome are a few comments and then the request will be assigned a low priority and not much else will happen. | ||
* You make it your own project to get feature XY implemented: <br/> This doesn't necessarily mean that you have to do everything yourself, but it means that you must actively manage what is happening rather than be content to put an idea out in writing and relax. If you're willing to do this, this guide is for you, please read on. | * You make it your own project to get feature XY implemented: <br/> This doesn't necessarily mean that you have to do everything yourself, but it means that you must actively manage what is happening rather than be content to put an idea out in writing and relax. If you're willing to do this, this guide is for you, please read on. | ||
| Line 32: | Line 34: | ||
# Flightgear relies on having a contributor base, but not on a user base: <br/> Unlike a commercial project which needs customers to survive, FG does not. A commercial project is sustained by paying customers, so that the company can pay its workers. In FlightGear, "workers" are generally not paid. And a self-sustaining project depends very much on contributors. As a result, FG development is not focused on the end user. Developers, and other contributors, tend to work on ideas and features they would like to see, scenery contributors work on areas of the world they are interested in - the project works on the basis of people devoting their spare time to creating the simulator they want to have. This means that arguments along 'If feature XY will be implemented, many more users will join the community.' or 'If feature XY is not implemented, many users will use FSX instead.' will leave developers unimpressed, but arguments like 'If feature XY is implemented, it allows new contributors to improve the simulator in that way.' will be regarded as more interesting. And this is something that is generally true in the wider context of the FlightGear history: technology-enablers improving accessibility and usablity that ended up getting more people involved, generally helped the simulator and community to grow over time. | # Flightgear relies on having a contributor base, but not on a user base: <br/> Unlike a commercial project which needs customers to survive, FG does not. A commercial project is sustained by paying customers, so that the company can pay its workers. In FlightGear, "workers" are generally not paid. And a self-sustaining project depends very much on contributors. As a result, FG development is not focused on the end user. Developers, and other contributors, tend to work on ideas and features they would like to see, scenery contributors work on areas of the world they are interested in - the project works on the basis of people devoting their spare time to creating the simulator they want to have. This means that arguments along 'If feature XY will be implemented, many more users will join the community.' or 'If feature XY is not implemented, many users will use FSX instead.' will leave developers unimpressed, but arguments like 'If feature XY is implemented, it allows new contributors to improve the simulator in that way.' will be regarded as more interesting. And this is something that is generally true in the wider context of the FlightGear history: technology-enablers improving accessibility and usablity that ended up getting more people involved, generally helped the simulator and community to grow over time. | ||
# Developers are free to do what they want: <br/> This should be pretty obvious given the nature as an all-volunteer project, but in reality it is not, so it's worth pointing out: FG developers work for the project in their free time, they have work and family obligations just like other people, and they have every right to not work on FG or to not code a feature even if a majority of users or developers thinks it is very important. The implication is that if you like anyone to help you, you need to convince him to do it voluntarily. | # Developers are free to do what they want: <br/> This should be pretty obvious given the nature as an all-volunteer project, but in reality it is not, so it's worth pointing out: FG developers work for the project in their free time, they have work and family obligations just like other people, and they have every right to not work on FG or to not code a feature even if a majority of users or developers thinks it is very important. The implication is that if you like anyone to help you, you need to convince him to do it voluntarily (this is for example how this article came into existence, without the person suggesting it, being originally involved in creating it). | ||
# Flightgear development tends to be inclusive: <br/> There is strong concern throughout the development community about making FG impossible to use for some hardware setups or dropping existing features, and all such changes tend to be discussed in length (over months or even years). Usually new features are therefore implemented in an optional way. If the feature you have in mind will mean abandoning support for an existing feature, you will have a hard time getting support even if it has clear benefits (the devel community did for instance not support the use of compressed dds textures despite their obvious benefits in terms of loading time and GPU memory consumption for the reason that they can't be run by Linux-users with non-proprietary graphics drivers). | # Flightgear development tends to be inclusive: <br/> There is strong concern throughout the development community about making FG impossible to use for some hardware setups or dropping existing features, and all such changes tend to be discussed in length (over months or even years). Usually new features are therefore implemented in an optional way. If the feature you have in mind will mean abandoning support for an existing feature, you will have a hard time getting support even if it has clear benefits (the devel community did for instance not support the use of compressed dds textures despite their obvious benefits in terms of loading time and GPU memory consumption for the reason that they can't be run by Linux-users with non-proprietary graphics drivers). | ||
# FlightGear being not focused on end-users, it may often not be as accessible/usable as a more polished/commercial piece of software. This has several reasons, which are explained below. | |||
Obviously, we would all like to have a flight simulator that provides for an experience that doesn't involve a steep learning curve. | Obviously, we would all like to have a flight simulator that provides for an experience that doesn't involve a steep learning curve. | ||
Often, people tend to compare usability (or lack thereof) to some great GUI tools available in proprietary simulators. Historically, however, we've learned that implementing such extremely high level end user features doesn't scale all that well. We've seen several years of time spent developing high-level features in C++ space that got quickly re- | Often, people tend to compare usability (or lack thereof) to some great GUI tools available in proprietary simulators. Historically, however, we've learned that implementing such extremely high level end user features doesn't scale all that well. We've seen several years of time spent developing high-level features in C++ space that got quickly re-implemented, or even replaced, once middleware developers had sufficient tools at their disposal to customize the simulator through XML and scripting (for example, the existing weather system is more feature-rich than any previous weather system developed by core developers). Besides, it generally works better for the community to reuse existing tools whenever possible - no matter if it's Blender for 3D modeling, Inkscape for vector graphics, GIMP for texturing, or even just a conventional text editor for XML/script editing. Coming up with such tools from scratch, as is common in commercial software projects, would be a huge effort - obviously, having to use generic tools, also means that usability may lack at times. | ||
What this means is that developing high-level end-user features through core development often doesn't scale as well as using existing tools, customize those or just exposing the infrastructure required to allow middleware developers to implement certain features directly through existing FlightGear extension mechanisms. | What this means is that developing high-level end-user features through core development often doesn't scale as well as using existing tools, customize those or just exposing the infrastructure required to allow middleware developers to implement certain features directly through existing FlightGear extension mechanisms. | ||
| Line 45: | Line 48: | ||
== Test the waters == | == Test the waters == | ||
If you want your idea to be part of Flightgear in the end and not a fork or an addon, test the waters early on. Working for a year on some project which won't be committed in the end is frustrating for both sides. Use the forum or the mailing list to talk to people, get a feeling for how the response is, just don't leave it there. It is always a good idea to announce your project on the forum, you can also use the [[Newsletter]] to make announcements. If your project is in any way about software or the base package, another good idea is becoming familiar with using git and gitorious and using it to conduct development in the open, so that others can track your work and provide feedback. | If you want your idea to be part of Flightgear in the end and not a fork or an addon, test the waters early on. Working for a year on some project which won't be committed in the end is frustrating for both sides. Use the forum or the mailing list to talk to people, get a feeling for how the response is, just don't leave it there. And make sure that you're aware of who you're talking to, there's often a ton of end-user feedback, but little development from other contributors, which is however the only thing that matters to get your work accepted and included. | ||
It is always a good idea to announce your project on the forum, you can also use the [[Newsletter]] to make announcements. If your project/idea is in any way about software or the base package, another good idea is becoming familiar with using git and gitorious and using it to conduct development in the open, so that others can track your work and provide feedback. This in and of itself demonstrates to long-term developers that you are to be taken seriously, because your development process is transparent and can be easily tracked. | |||
Some events that have occurred in the past, and what to learn from them: | Some events that have occurred in the past, and what to learn from them: | ||
| Line 54: | Line 59: | ||
* The bombable addon providing support for air combat could not be committed because the devel community feels strongly that FG should remain a civilian aviation simulator. Lesson: Test the waters, see what the response to an idea from developers who can commit are. They will decide, regardless of what users say. | * The bombable addon providing support for air combat could not be committed because the devel community feels strongly that FG should remain a civilian aviation simulator. Lesson: Test the waters, see what the response to an idea from developers who can commit are. They will decide, regardless of what users say. | ||
* Huge patches for novel features were announced shortly before a release, providing little time to thoroughly test and integrate the patches in time for the release, while also creating a huge workload for other developers who were not aware of the effort, and may have made conflicting changes in the meantime - something like this can be prevented by using gitorious regularly, and by getting touch with other developers to make them aware of your plans, but also your implementation strategies - ideally, asking for feedback on how to proceed best in order to avoid coding conflicts. | |||
== Gather information == | == Gather information == | ||
Regardless if you want to proceed on your own, or if you want to find people to help you - you need information. If you want to see a new visual effect implemented, at minimum you need to find out who inside the FG project can help you, even better is to have an idea what options FG provides, how the effect framework works, how effects are configured etc. The Wiki is your friend, but usually if you show some interest, people in the forum will post helpful links. If you want to be taken seriously later, work through the information and make sure you know what you're talking about. | Regardless if you want to proceed on your own, or if you want to find people to help you - you need information. If you want to see a new visual effect implemented, at minimum you need to find out who inside the FG project can help you, even better is to have an idea what options FG provides, how the effect framework works, how effects are configured etc. The Wiki is your friend, but usually if you show some interest, people in the forum will post helpful links. If you want to be taken seriously later, work through the information and make sure you know what you're talking about. It is also a good idea to look up who's previously done related work, or who's recently been working on similar ideas and projects, so that you know who to get in touch with. Usually, other community members will be glad to provide pointers to related projects and their contributors. | ||
| Line 70: | Line 77: | ||
* ... be as concrete as possible, point out what precisely you would like to see changed. | * ... be as concrete as possible, point out what precisely you would like to see changed. | ||
* ... demonstrate that you have looked at the relevant information and know what you're talking about | * ... demonstrate that you have looked at the relevant information and know what you're talking about | ||
* ... provide a summary of your main ideas using the wiki, in case the discussion leads nowhere, people can still pick up the whole thing at a later time | |||
Don't... | Don't... | ||
| Line 75: | Line 83: | ||
* ... demand anything from anyone. | * ... demand anything from anyone. | ||
* ... be rude or angry if people are critical - it's part of the process. | * ... be rude or angry if people are critical - it's part of the process. | ||
* ... point out how bad FG is going to be or how it will fail if your idea is not implemented. | * ... point out how bad FG is going to be or how it will fail if your idea is not implemented | ||
* ... say you can't do anything, because you don't understand C++ - the human mind can learn | * ... say that you're going to abandon the project or switch to a commercial product | ||
* ... say you can't do anything, because you don't understand C++, coding or XML - the human mind can learn | |||
Compare 'Wouldn't it be cool if we had better-looking cities like X-Plane?' with 'Would it be possible to make the random building shader configurable such that it loads a pre-defined set of 3d models and assembles them in naturally looking groups by a placement mask of this and that format? I would then take care of the buildings and textures, but I'd need some help with the code. Here's a picture of how FG could look like.' - which of the two proposals would you support? | Compare 'Wouldn't it be cool if we had better-looking cities like X-Plane?' with 'Would it be possible to make the random building shader configurable such that it loads a pre-defined set of 3d models and assembles them in naturally looking groups by a placement mask of this and that format? I would then take care of the buildings and textures, but I'd need some help with the code. Here's a picture of how FG could look like.' - which of the two proposals would you support? | ||
Even good proposals have a fair chance of failing to get any support. The reason is that experience has shown that the majority of people who say that they would do X if only feature XY is implemented do in fact not do X afterwards. Which is to say, before starting to join a project, developers want to be reasonably sure that their work will not be in vain because you lose interest and walk away. The magic words here are 'track record' and 'proof of concept', you can help improve you signal/noise ratio significantly by ensuring that you follow up on your commitments and do the necessary behind-the-scenes networking to implement a new feature or project. It is this combination of having a track record, "credit" and a good signal/noise ratio that will ultimately give you certain ''leverage'' when interacting with other contributors. | Even good proposals have a fair chance of failing to get any support. The reason is that experience has shown that the majority of people who say that they would do X if only feature XY is implemented do in fact not do X afterwards. Which is to say, before starting to join a project, developers want to be reasonably sure that their work will not be in vain because you lose interest and walk away. The magic words here are 'track record' and 'proof of concept', you can help improve you signal/noise ratio significantly by ensuring that you follow up on your commitments and do the necessary behind-the-scenes networking to implement a new feature or project. | ||
It is this combination of having a track record, or "credit", and a good signal/noise ratio that will ultimately give you certain ''leverage'' when interacting with other contributors. | |||
Overall, time spent contributing to the project really '''is''' our "currency-it shows dedication and discipline and it demonstrates to potential collaboratos that you are serious about your commitments, and that teaming up with you is not a waste of their time. If properly done, such networking can be a great multiplier/lever. | Overall, time spent contributing to the project really '''is''' our "currency-it shows dedication and discipline and it demonstrates to potential collaboratos that you are serious about your commitments, and that teaming up with you is not a waste of their time. If properly done, such networking can be a great multiplier/lever. | ||
If you already have a history of bringing projects to a conclusion, people are far, far more likely to support you. If you have not, because you're just starting out, the best thing you can do is a proof of concept. Perhaps something should really be in C++ for performance reasons - but you can make a simple proof of concept in Nasal scripting space. Once people see that you're actually investing time and work rather than talk, and once they can see what you want to do, you're again more likely to get support. | If you already have a history of bringing projects to a conclusion, people are far, far more likely to support you. If you have not, because you're just starting out, the best thing you can do is a proof of concept. Perhaps something should really be in C++ for performance reasons - but you can make a simple proof of concept in Nasal scripting space. Once people see that you're actually investing time and work rather than talk, and once they can see what you want to do, you're again more likely to get support. | ||
Finally, proposals failing may still happen for other reasons, such as bad timing, lack of man power, people being busy with other aspects of FG or RL etc. | |||
This happens even to long-term contributors regularly, including core developers. | |||
== Getting People involved == | == Getting People involved == | ||
| Line 97: | Line 111: | ||
People are not just motivated by '''ideas''' but by actions that materialize, and short of that, by saving their own time. | People are not just motivated by '''ideas''' but by actions that materialize, and short of that, by saving their own time. | ||
Sometimes, it may be helpful to not just introduce the final outcome, but also the pathway to make it happen. | |||
Usually, most contributors have different ideas about FlightGear, and very different priorities, skills and expertise. | Usually, most contributors have different ideas about FlightGear, and very different priorities, skills and expertise. | ||
So the point really is compromising. Finding overlapping areas of interest, i.e. common goals. Very often, that means that people may not directly work towards the original goal/project (such as for example an improved multiplayer system, a weather system or even combat support), but rather some interim milestones, as part of some longer-term '''roadmap'''. | So the point really is compromising. Finding overlapping areas of interest, i.e. common goals. Very often, that means that people may not directly work towards the original goal/project (such as for example an improved multiplayer system, a weather system or even combat support), but rather some interim milestones, as part of some longer-term '''roadmap''' or bigger picture. | ||
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. | |||
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 until they join some other 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. | |||
This may seem frustrating at first, but you should cherish such opportunities, no matter how short-lived they may be, for they provide an excellent networking opportunity, getting more people involved in your project, but also to become better known to fellow contributors. | This may seem frustrating at first, but you should cherish such opportunities, no matter how short-lived they may be, for they provide an excellent networking opportunity, getting more people involved in your project, but also to become better known to fellow contributors. | ||
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. | 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. | ||
In general, it is unlikely that you'll be able to directly form a team of people who fully share your motivation, goals and roadmap - and even then, you may find yourself missing other components that are required for a successful project, such as expertise in certain areas (3D modeling, texturing, programming, scripting, effects or shaders etc). | |||
This is why you'll typically have to reach out to 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, to contribute to similar projects first, before asking others to contribute to theirs. | |||
Typically, this means that you must be willing to adjust your own priorities - while it may seem of utmost important to you to work on feature X, some other contributor may be more interested to work on something that you don't consider extremely important, or maybe even making concessions that you don't consider acceptable - this is where most people fail big time, discussions start becoming enormous, vocabulary harsh - and at some point, there's no collaboration feasible anymore. | |||
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. | But this is one of the most important aspects of successfully "bootstrapping" a new project: finding overlapping areas, contributors who can help with related efforts, and making compromises, i.e. accepting that you have to walk before you run. | ||
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, depending on the viewpoint - typically, there's at least a handful of needs that projects may have in common. Sometimes, you may need to extend your own plans beyond what seems reasonable to you, while limiting your original goals to a subset of the original idea, just to get something started. | |||
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. | 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. | 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 and certain skills, 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". | For instance, some of our most active contributors have very little time to provide support to end-users or even just to 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". | ||
There are some contributors who have never contributed to the software itself directly, still they managed to shape the project through lots of feedback, simply because they have become important in other aspects of the project, which are also important - no matter if it's the forum, the wiki or other aspects of the infrastructure surrounding the project. | |||
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. | 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. | ||
== Be persistent == | == Be persistent == | ||
If you fail to get help you need, think about why. There may be fair reasons for it - your priority may not be everyone else's priority, or some criticism may not be mean but actually valid, or your contribution isn't apparent enough - go back and try to revise the proposal. If you can't get help in some area, perhaps there's a workaround which is less perfect? Nasal often is a viable alternative to C++, and subsystems can always be converted later. Trying to get things perfect up-front is likely to get you nowhere, because making things perfect is very hard - starting with something 'good enough' and improving it is more likely to succeed. If your project is truly good, it will get support on the way. Investigate your idea critically, but if you truly believe in your idea, stay with it and make it work in some form. | If you fail to get help you need, think about why-and don't take it personally. There may be fair reasons for it - your priority may not be everyone else's priority, or some criticism may not be mean but actually valid, or your contribution isn't apparent enough - go back and try to revise the proposal. If you can't get help in some area, perhaps there's a workaround which is less perfect? Nasal scripting often is a viable alternative to C++, and subsystems can always be converted later. Trying to get things perfect up-front is likely to get you nowhere, because making things perfect is very hard - starting with something 'good enough' and improving it is more likely to succeed. If your project is truly good, it will get support on the way. Investigate your idea critically, but if you truly believe in your idea, stay with it and make it work in some form, i.e. to build momentum over time. Seriously, the perfect is the enemy of the good here - we've seen countless of good proposals that simply failed because people were not willing to make concessions, people would see problems with any workaround and imperfect solution suggested by others - so what they ultimately got in return was a "perfect" design, discussed across hundreds of postings, usually wasting dozens of manpower hours of in the process. | ||
As an example, in the beginning the idea of using Nasal to implement a full weather system was not taken seriously by anyone in the development community. Once written in a very inefficient but working way, the system however did get lots of help from developers on the C++ side and is now known as Advanced Weather, one of the most sophisticated weather systems which exist in a flight simulation. | As an example, in the beginning the idea of using Nasal to implement a full weather system was not taken seriously by anyone in the development community. Once written in a very inefficient but working way, the system however did get lots of help from developers on the C++ side and is now known as Advanced Weather, one of the most sophisticated weather systems which exist in a flight simulation. | ||
Likewise, one of the most-heated discussions in the history of the FlightGear forum involved bringing space flight or combat support to FlightGear - these discussions took place over many years, brought up by various individuals - but most people would only see the limitations in the suggested approaches, so that the system they envisioned was never implemented - and in retrospective, it would have taken them a tiny fraction of the time spent debating with others to come up with a very basic working prototype, which is a great momentum builder. | |||
== Honor your commitments == | == Honor your commitments == | ||
| Line 143: | Line 167: | ||
And more often than not, the general truth is that people -especially newcomers- are unlikely to do a forum/devel list search in order to dig out some discussion that took place many years ago, just to learn about a project, its status, the ideas and the people that were involved. | And more often than not, the general truth is that people -especially newcomers- are unlikely to do a forum/devel list search in order to dig out some discussion that took place many years ago, just to learn about a project, its status, the ideas and the people that were involved. | ||
Thus, it is up to you to see how much momentum there really is, or if a certain topic tends to be a "time-waster", i.e. taking up lots of time to deal with, with very little materializing in terms of features - sometimes, those are long-standing features, such as being able to reset/re-init the simulator, or even save/load flights and switch aircraft at run-time. These are popular feature requests and there are dozens of discussions related to these, so it is usually not a good idea to start yet another debate - this is where a less-conversational platform (like the wiki) can be a great tool, so that ideas, proposals, community support and project status can be documented over time. | Thus, it is up to you to see how much momentum there really is, or if a certain topic tends to be a "time-waster", i.e. taking up lots of time to deal with, with very little materializing in terms of actual features - sometimes, those are long-standing features, such as being able to reset/re-init the simulator, or even save/load flights and switch aircraft at run-time. These are popular feature requests and there are dozens of discussions related to these, so it is usually not a good idea to start yet another debate - this is where a less-conversational platform (like the wiki) can be a great tool, so that ideas, proposals, community support and project status can be documented over time. | ||
'''Time''' really being the keyword here - some topics are not about a single isolated feature that can simply be implemented by some random developer, those are often large-scale architectural changes, or even proposals to change parts of the project's philosophy (see [[Release Plan]]) or some of its infrastructure (e.g. the [[FlightGear Build Server]]). Thus, these topics are often not about people disagreeing that something needs to be done, but the suggestion really is a long-term item, that needs to be tackled over time - typically many months, often several years and also by different people. | |||
Here, using the wiki to present your ideas, and document related discussions, proposals and supporters, can be a great tool to aid building up momentum over time, while providing an entry point for people interested in a certain topic. For instance, some of the aforementioned flamewars ended up having ~4000 views in over 2 years, compare that to wiki articles covering the same topic, getting 12k views in just a few months. Go ask yourself, how would you prefer to be introduced to some novel idea that you may want to work on at some point ? | |||
We've had a number of efforts that got discussed for years before they finally got implemented. This included for example the PLIB/OSG migration, and the HLA and reset/re-init efforts are other ongoing examples for this. Typically, complex ideas may very well have a shelf life of several months - often even, 12-18 months. The [[Canvas]] system only took shape 18 months after it had been introduced on the FlightGear wiki for example. | |||
Thus, sometimes good ideas may take time to materialize - and whenever timing doesn't seem to work, it's a good idea to let time work for you, by creating a corresponding wiki article to document something, and maintaining it over time, e.g. by adding links, quotes or references to related discussions. | Thus, sometimes good ideas may take time to materialize, for momentum to build up - and whenever timing doesn't seem to work in your favor, it's a good idea to let time work for you instead, by creating a corresponding wiki article to document something, and maintaining it over time, e.g. by adding links, quotes or references to related discussions. To provide another example: We've had various discussions on coming up with a scenery build server, and this is something that is slowly starting to materialize now - largely thanks to having a dedicated wiki article presenting an overview about past discussions and ideas, and all this took really just a few months - but those were spread across almost 3 years now. But the wiki article allowed us to still build on existing ideas and discussions, without requiring people to spend hours in the archives. | ||
Make your efforts available for testing early - let people play with it and get ideas from it. Only a well-working project should go directly to the FG repositories, but there's plenty of ways to distribute your efforts before that. When it's ready and tested, make a merge request on GIT, talk to a person who has commit rights and is able to test your work, and enjoy your feature being part of the next release. | Make your efforts available for testing early - let people play with it and get ideas from it. Only a well-working project should go directly to the FG repositories, but there's plenty of ways to distribute your efforts before that. When it's ready and tested, make a merge request on GIT, talk to a person who has commit rights and is able to test your work, and enjoy your feature being part of the next release. | ||