Board index FlightGear The FlightGear project

Request for a modernized FGRUN

Questions about the FlightGear organisation, website, wiki etc.

Re: Request for a modernized FGRUN

Postby Thorsten » Fri May 08, 2015 7:50 am

I did not intend to come across as demanding, but more thinking of encouraging perhaps the development of another user base (which partially included myself) that at least I had the feeling was turned down pretty quickly by the style in which the program comes across, partially due to not having the overview of the tools that they felt were important.


Let's say that given the choice of making the sim better or play with cool things like spaceflight and developing a different user base, the user base is not a priority for me. And that's probably a more widely spread sentiment among developers.

From a project POV, what's mainly interesting is attracting tinkerers - we're not really advertizing or trying to convert users from FSX, and the number of users who just use FG is fairly unimportant for the project (we don't need to sell after all).

So, I want to dump my energy into creating a highly realistic weather system, or model light filtering through the atmosphere accurately to get realistic visuals, or to create outstanding flight dynamics and I'm mostly interested in meeting users who appreciate the same things, i.e. a high level of realism in the sim. I'm not sure what to make of a user who says 'highly realistic sim is all nice, but the GUI looks crappy' - perhaps this kind of user genuinely is better off with FSX. I don't really see this as a competition - we simply cater for different kinds of users.
Thorsten
 
Posts: 11463
Joined: Mon Nov 02, 2009 8:33 am

Re: Request for a modernized FGRUN

Postby Hooray » Fri May 08, 2015 2:51 pm

I have to agree with Thorsten: attracting "tinkerers" (those who want go get involved in modifying/extending the simulator) is analogous to "fueling" the project, i.e. it's the main currency that counts, not unlike a commercial project which needs to make revenue and profits to pay its developers - FlightGear developers/contributors aren't paid, so they need be motivated and rewarded differently, e.g. by allowing them to work on their area/s of interest, and spending time doing things they enjoy - which is how the project is kinda "self-organizing", with people listening carefully to what other contributors are interested in, and their track records - to identify overlapping areas and efforts, and see if/how these can be coordinated to end up with a greater RoR.

This may sound unpopular for people not interested in contributing, especially those whose primary argument usually is that they /might/ become contributors at some point - but usually, that's really a moot point.

Which is also why it pays off for us to focus on providing support to other contributors/developers, instead of just end users - simply because there's much better leverage then. For instance, back when Thorsten started out here, some of us ended up supporting him - considering his results (screen shots, released scripts etc) as our "reward" - let's assume, that a new contributor receives ~50 hrs of support from other contributors - the same time spent supporting others (primarily end-users) does rarely -if ever- have such a great RoR.

In general, that is how most FG related efforts are likely to work behind the scenes - ideally, by people networking with others to find the corresponding skills/expertise and convince them to help with a certain effort, even if just temporarily.

From my standpoint, a nicer UI would be "nice" to have (and is in fact being woked on), but my focus would never be to attract more end users, hoping to turn them into contributors - in fact, I'd argue quite the opposite: end-users claiming that they cannot get involved right now, due to FlightGear's GUI, are demonstrating a lack of patience and willingness WRT FG internals - which would almost certainly apply just as well to a future scenario, where a new UI may be available - and in fact, given ~3 different/independent recent UI efforts, I don't see any reasons for people -genuineley interested in an improved UI- not to get involved.

Which is meant to say that there may be a certain barrier to entry depending on your area of interests - but that also serves as a "filter" to help others determine how strongly someone is motivated, and how willing/able someone is able to follow up on his requests.

Which kinda sums up, why I ended up spending roughly ~20 hours to set up Thorsten with a working build environment a few years ago, despite him not being interested in cvs/git or cmake stuff - I knew how to script this stuff, and it was also obvious that Thorsten would regularly share his results (not just screen shots, but actual code/features) with us. Also, he was working on stuff that nobody else was working on, but that everybody appreciated.

Meanwhile, Thorsten is doing of fancy, and unprecedented stuff, that even most of us long-timers would not have been able to do in the same time frame - so whenever Thorsten is posting an update/patch or even just screen shots, it's kinda a "pat on our shoulder" looking back, knowing that we belonged to those who were trying to make this a positive experience from the get-go, while also understanding that some/many recent interactions may no longer be as positive :D

While this may sound a bit pompous, especially to Thorsten -given that he did all the hard work- it goes to show that there's a certain thought process involved, and no matter what side you're on, it does help to understand how this works.

I think I once mentioned this elsewhere: you could look at the way this works by looking at business angels assigning their venture capital: in the case of FG, our "capital" is our spare time, in combination with our expertise and skills that we can share with others, i.e. to "bootstrap" them and get them going until they've reached a point of self-sufficiency - at which point, they'll hopefully also adopt such a "business angel" attitude and look at the community to share their own time and skills with other contributors.

However, knowing fully well that many such efforts get killed early on, it does make sense to "cast your net wide" - and unless someone already has a certain track record, you'll end up supporting a handful, or maybe even a dozen different efforts at the same time - ideally, in a fashion that is not specific to a single contributor being a hit/miss (e.g. using the wiki to document efforts/projects, instead of "people").

Which also sums up the reasons why it is easier for certain contributors to bootstrap new projects, because they already have a track record and reputation/long-evity, while others are difficult to judge.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11598
Joined: Tue Mar 25, 2008 8:40 am

Re: Request for a modernized FGRUN

Postby onox » Fri May 08, 2015 4:24 pm

Thorsten wrote in Fri May 08, 2015 7:50 am:So, I want to dump my energy into creating a highly realistic weather system, or model light filtering through the atmosphere accurately to get realistic visuals, or to create outstanding flight dynamics and I'm mostly interested in meeting users who appreciate the same things, i.e. a high level of realism in the sim. I'm not sure what to make of a user who says 'highly realistic sim is all nice, but the GUI looks crappy' - perhaps this kind of user genuinely is better off with FSX. I don't really see this as a competition - we simply cater for different kinds of users.


Would you buy a Lamborghini if it looked like a Fiat Multipla? No.

If you want more tinkerers, you first need more users, because tinkerers initially start as users. So you need to increase the user base. If a project looks dead because it's barely being used, then it's not going to attract many future contributors. Users are necessary evil for projects.

Also, core devs should look at how they can make it easier for people to start contributing. Currently, the mailing list is an engine with no oil. If simple patches takes weeks before they are committed, then how much time will it take for larger contributions? If a simple patch has a high probability to take too much time or even be just ignored, then why would I work on a large and significant contribution at all? Why would I then invest time to set up my own build environment?

Hooray wrote in Fri May 08, 2015 7:50 am:with people listening carefully to what other contributors are interested in, and their track records - to identify overlapping areas and efforts, and see if/how these can be coordinated to end up with a greater RoR.


Do you know how much of a track record a new contributor has? Zero, none, nada, niente. You might want to listen to them as well.
onox
Retired
 
Posts: 431
Joined: Fri Jun 20, 2014 2:45 pm

Re: Request for a modernized FGRUN

Postby Hooray » Fri May 08, 2015 4:55 pm

onox wrote in Fri May 08, 2015 4:24 pm:
Hooray wrote in Fri May 08, 2015 7:50 am:with people listening carefully to what other contributors are interested in, and their track records - to identify overlapping areas and efforts, and see if/how these can be coordinated to end up with a greater RoR.


Do you know how much of a track record a new contributor has? Zero, none, nada, niente. You might want to listen to them as well.


Of course I do - which is why you can see that contributors tend to look at prerequisites/requirements for certain efforts - for instance, if someone is familiar with C++ or even has already succeeded setting up a build environment, that will give him/her certain attention - as well others having demonstrated skills in related areas (e.g. Nasal coding). But someone suggesting to revamp the FG GUI without a background in coding and without having set up a working build environment, would have to face quite a steep learning curve until recently - thanks to TheTom's Canvas/Nasal work and Torsten's Phi/mongoose work, even Nasal scripting and DHTML5 can be used to contribute to these areas in FG, without having to patch/build FG from source.

Then again, there's a huge tendency for people to get lost in irrelevan details, no matter if that's feature requests about space flight or combat support in FlightGear: most people tend to focus on irrelevant features that would not even be important anytime soon, had they a team of ~50+ experienced FG developers working towards them. Which is why it is so crucial to understand how to approach certain tasks, and in what order - i.e. what's required for implementing certain infrastructure in a top/down vs. bottom/up fashion, given the current situation.

Referring to you as an example onox: You ended up getting some attention from me, simply because you 1) demonstrated coding skills (e.g. in Nasal), 2) were apparently able to use git/gitorious, 3) build FG from source, 4) provided fgdata/fg patches. These factors can help make up for a missing track record.

Regarding the UI, given the current situation and the number of ongoing efforts related to this, I don't think anybody should be arguing that they won't use/contribute to FG due to its archaic UI: The AircraftCenter dialog is straightforward to work through with even just a little background in HTML5/JavaScript - equally, the Phi stuff is very acccessible- so people can get involved in this right away, even if that just means dabbling with different styling, or even localization - that alone can help get you some attention from other contributors who can povide pointers and code snippets to keep you going - which kinda is how Thorsten became a "rock star" around here: he made sure to "release & early often", sharing screen shots, patches and tarballs to get people interested and involved at some point - with many efforts having been coordinated behind the scenes.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11598
Joined: Tue Mar 25, 2008 8:40 am

Re: Request for a modernized FGRUN

Postby Johan G » Fri May 08, 2015 6:14 pm

I am speculating wildly here, but could it be that many of the patches that have been laying around for ages are very large and/or complex? In essence taking a lot of (or rather too much) effort to review.

I got reminded by this as you said (and I am probably quoting slightly out of context here):
Hooray wrote in Fri May 08, 2015 4:55 pm:... which kinda is how Thorsten became a "rock star" around here: he made sure to "release & early often", sharing screen shots, patches and tarballs to get people interested and involved at some point ...



Edit:

I will elaborate a little on that. It was not really till I saw Fitz' and Ben's presentation mentioned in this post (or possibly the one int this post) that I understood one of the points with 'release early and release often'.

They at some point talked about 'powerplants' vs. 'bike sheds'. That is large nearly non-reviewable opaque contributions that either get accepted or not, but with often surprisingly little discussion, vs. small, nearly cosmetic contributions that can stir up a 'minor' flame war.

The key point seemed to be: Do not sit too long working alone in your 'cave' on something. Rather, work within the community one step at a time. It is easier to review and accept smaller contributions.
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 5634
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 3.0.0
OS: Windows 7, 32 bit

Re: Request for a modernized FGRUN

Postby Thorsten » Mon May 11, 2015 6:50 am

If simple patches takes weeks before they are committed, then how much time will it take for larger contributions? If a simple patch has a high probability to take too much time or even be just ignored, then why would I work on a large and significant contribution at all?


I guess it starts out with the simple truth - you work on something because you find it interesting /cool/ want to have it. Then you end up having it if you succeed.

Spending a year coding a complicated patch without talking to anyone and then making a merge request is first and foremost bad strategy in a community. When I need /want to make changes to the core code, I first look at the area I need to modify and try to understand it, then get in touch with the people who maintain it if I can reach them and discuss my plans. Sometimes I drop my idea at this point, because I learn that I've overlooked something important. Only after I have a clear picture of what I want to do and what the current maintainer thinks is reasonable, I start actually coding. In this way, the basic idea of my patch is cleared before I start investing significant work, I get help on the way, and the review in the end is mainly about technicalities which are easily cleared out of the way.

I mean, if you ignore the development community while writing your patch, you can't really complain if your patch fares similarly (even so, often they don't). Whereas if you work together with people from the start and try to harness their ideas as well, chances that your contribution is ignored later are close to zero.

Likewise, if you have something completely modular and 'risk-free', people are much more likely to commit it than something that has a high chance of causing lots of breakage.

If you want more tinkerers, you first need more users, because tinkerers initially start as users. So you need to increase the user base. If a project looks dead because it's barely being used, then it's not going to attract many future contributors.


I know the argument, but I don't think it is true.

First, FG looks very much not dead - given the amount of reviews and features it gets (most recent presented as special highlight by SourceForge two times in a row) I gather it even has quite some reputation in the Linux community.

Second, users are not all equal. In a way, I of course started FG as user, but I'm a Linux person, so my first reaction when something wasn't looking quite so nice (I was bothered that the cap clouds of the AI thermals for glider flight looked all the same) was 'This is just some xml and texture files - I can fix that.' A user who is bothered by the GUI but does not experience the reaction 'Hey, I can fix that' is unlikely to become a tinkerer.

As I said earlier, I don't know of a single case historically where better visuals have caused more people to contribute to FG (if you compare 2.0 which came out about when I entered FG with 3.6 in terms of visuals during flight, you'll see lightyears of development of shader effects, procedural texturing, light simulation, weather,...) which surely is much much more important than the GUI for the experience. Yet - the rate of developers joining the project seems remarkably independent of that.

So my counter-argument is, as Hooray said, that the kind of people who really care how the GUI looks like and don't have the immediate impulse to get the editor fired up and fix it are unlikely to ever become developers.

Do you know how much of a track record a new contributor has? Zero, none, nada, niente. You might want to listen to them as well.


Every day, there's a dozen people in the forum who want me to listen to them. I don't have that kind of time. Maybe you do, but I can't spend six hours a day in the forum.

So I pick the most promising voices. This may not be what is fair in an ideal world, but it is what is possible in the real world.
Thorsten
 
Posts: 11463
Joined: Mon Nov 02, 2009 8:33 am

Previous

Return to The FlightGear project

Who is online

Users browsing this forum: No registered users and 0 guests