Re: [Flightgear-devel] Chaos in FG development [was: Bomb patch for vulcanb2]
FlightGear development has exploded to the point where it *really* needs a full time manager or even a management team. How does that happen though in the context of an open-source project where everyone is volunteering their slivers of time and everyone has real day jobs and families and maybe an occasional life outside of the computer world? I'm not able to *volunteer* 100% of my effort to manage the flightgear project. I have my day job, I have a family with 2 small girls. Outside of that, my spare time is precious and limited. I sneak as much as I can for FG, but there are real limits to how much I can do. I don't have time review every patch idea, I don't have time to investigate every bug report, often, I can't even read every mailing list message in a timely manner, I certainly don't have time to weigh in on every flame war or rant. Is there anyone or any group or company out there willing to step forward and talk about funding a full time (or even 50% time) project manager? For what it's worth, some of the paying tasks I do are a real drag. I'd be willing to do more interesting paying tasks! I'd love to be able to dedicate more of my day back to FlightGear. As has been mentioned before, often open-source projects have a developer or two that are funded to accomplish some specific task within the project. That has happened occasionally on a very limited scope even with FlightGear. But who would want to fund a dedicated project manager that keeps all the lose ends neatly tied up and keeps the project heading in a sane direction, pushes out releases in a timely manner, spends some time marketing and promoting the project, etc. etc.? There isn't a direct and immediate coding value to that. No immediate payoff to a company that is focused on solving some specific problem for themselves and moving on to other things. Right now we depend on a precious few people who really know the code backwards and forwards and just get the project so to speak. However, there is so much work todo, that there is a very real danger that these people will burn out and dissappear. What happened to David Meggison and Erik Hofman? At some point people realize their jobs and their families are suffering and they can't do this 24/7. Do we want to talk about creating some sort of more formal organization like a non-profit? But there again, it takes someone who understands the process, and can devote a significant amount of time to managing the organization and being responsible for tax reporting and all the other fun stuff that goes along with a non-profit organization. That's pulling someone away from managing the actual project development, not to mention pulling someone away from actual coding. Is there a way to make a leap from a hobby project to a full blown non-profit with serious money exchanging hands? Maybe a paid organization manager, a paid project manager? Where could we generate income to the level of supporting a full time person or two? I believe there could be a huge amount of monitary value in FlightGear, but how do you effectively harness that since we give it away for free? Consulting? But then you have to deliver a specific result in a specific time frame which works against having time for larger project and organization management issues. Without sufficient cash flow to support a full time person or two, how do we move beyond the current situation where we are depending on slivers of volunteer time to accomplish everything that needs to get done? And even if we wanted to get smarter, it still takes significant time for someone to come up with strategies for more effectively using the individual slivers of time. It appears that we have hit or are near to hitting some sort of ceiling in the open-source world. Is there a way to break through to the next level? Perhaps there is a company or organization or individual with resources who has enough interest in FlightGear that they would be willing to help us grow to a new level? Curt. -- Curtis Olson - University of Minnesota - FlightGear Project http://baron.flightgear.org/~curt/ http://www.humanfirst.umn.edu/ http://www.flightgear.org Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Chaos in FG development [was: Bomb patch for vulcanb2]
--- Curtis Olson wrote: FlightGear development has exploded to the point where it *really* needs a full time manager or even a management team. How does that happen though in the context of an open-source project where everyone is volunteering their slivers of time and everyone has real day jobs and families and maybe an occasional life outside of the computer world? I don't think we're realistically going to be able to raise funds to support of full or part time manager, and as you note, it is very unlikely that a company would pay for management as opposed to specific development. Do we manage to even cover our hosting costs with DVD world scenery sales? A far better approach is to look at how we can make our processes more efficient so that the management (of which you are the CEO) can make better use of their time. I think what is required is more delegation. Martin Spott mentioned on the list problems with getting the web-site updated promptly, presumably because you are the sole maintainer of the site, and have too much on your plate. I don't feel that the web-site is something that has to be maintained by the CEO - it could easily be delegated. Similarly, John Denker recently commented on the huge proportion of checkins made by Melchior Franz. Melchior does a quite incredible job ensure that the data tree in particular is kept in good order, and committing huge numbers of contributions. However, I'm sure his life would be much easier if more aircraft maintainers have commit permissions. The ocassional bug might fall through, but most maintainers have enough pride in their work to fix bugs, and Melchior would still have commit permissions... The Manual is a prime example of where delegation has worked extremely well. Martin and I both have commit permissions and have made significant changes without any need to bother anyone. Therefore, I think it would be a good idea for you to look at what can be delegated from your workload onto other people and suggest appropriate roles to the list. Of course, good delegation is one of the signs of good management :) -Stuart ___ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Chaos in FG development [was: Bomb patch for vulcanb2]
On 7/16/07, Stuart Buchanan [EMAIL PROTECTED] wrote: I don't think we're realistically going to be able to raise funds to support of full or part time manager, and as you note, it is very unlikely that a company would pay for management as opposed to specific development. Do we manage to even cover our hosting costs with DVD world scenery sales? A far better approach is to look at how we can make our processes more efficient so that the management (of which you are the CEO) can make better use of their time. I think what is required is more delegation. Martin Spott mentioned on the list problems with getting the web-site updated promptly, presumably because you are the sole maintainer of the site, and have too much on your plate. I don't feel that the web-site is something that has to be maintained by the CEO - it could easily be delegated. Similarly, John Denker recently commented on the huge proportion of checkins made by Melchior Franz. Melchior does a quite incredible job ensure that the data tree in particular is kept in good order, and committing huge numbers of contributions. However, I'm sure his life would be much easier if more aircraft maintainers have commit permissions. The ocassional bug might fall through, but most maintainers have enough pride in their work to fix bugs, and Melchior would still have commit permissions... The Manual is a prime example of where delegation has worked extremely well. Martin and I both have commit permissions and have made significant changes without any need to bother anyone. Therefore, I think it would be a good idea for you to look at what can be delegated from your workload onto other people and suggest appropriate roles to the list. Of course, good delegation is one of the signs of good management :) I don't disagree with anything you've said, but delegation is a lot harder than it looks. I need to find (a) someone qualified to do the work and (b) someone who can do it consistantly and isn't going to get overwhelmed after the first month and drop out of the picture. I've had several past delegation efforts derailed because things just didn't work out. Tasks are always harder and take a lot more time than you think at first. Things that look effortless when I do it might be a result of years of trial and error and experience to come up with a method or sequence of steps that work well. Something that looks easy from the outside, might turn out to be actually very difficult and time consuming and people just don't realize that until they volunteer to take over the task, but often that's the point where the delegation effort starts to fizzle. I probably shouldn't say things that are potentially inflamatory here, and I'm definitely not referring to you, and also I am not trying to minimize the efforts and energy that various talented people have put into our project ... but there are a few people involved in the list that have grown into perpetual whiners and can't seem to make any post at all without taking a direct or indirect jab at someone or some aspect of the project. Personally, I just don't have the time to counter all their claims or try to put their exagerations back into proper context, and after a while I'm just not able to respond to their messages in a useful way even if there is occassionally a valid point or a piece of good content in them. I'm reminded of the story about the boy who cried wolf ... And for whatever it's worth, personally the way I am wired, I don't respond well to negative motivation unless it's coming from someone who signs my paycheck where I have no choice... it's something that just doesn't work well with me, even if there is a valid point or need. For the record, 20 different people have commit access to various portions of the FlightGear repository. Addressing the specific case of the web site. The web site is in cvs. I'm not the only one that is authorized to make changes. However, I am the only one that can upload those changes to the actual server. Unfortunately, giving access to this last step of uploading content would involve personal passwords and the ability to affect my paypal account and a few other things that I'm somewhat nervous about handing off. Deligation is one of the main tasks of a paid manager with paid employees. Deligation is needed to get the overall job done as efficiently as possible. But in a context where a volunteer manager is dealing with volunteer developers, none of whom can devote 40-80 hours a week to the project, delegation becomes much harder. Actually, you can't even really call it delegation. What do you think would happen if I started picking names and assigning tasks and deadlines and demanding weekly reports?!? Instead I have to resort to trickery, mind games, and reverse logic to convince people who are already very busy that they should take on additional tasks ... and most of you are smarter than me and able to successfully defend against my best
Re: [Flightgear-devel] Chaos in FG development [was: Bomb patch for vulcanb2]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Curtis Olson wrote: Unfortunately, giving access to this last step of uploading content would involve personal passwords and the ability to affect my paypal account and a few other things that I'm somewhat nervous about handing off. Isn't there some possibility to create new accounts with upload permission, which don't involve giving your personal password? If uploading via scp or sftp is possible, one could even use the same account with different ssh-keys. Unless the FG page is hosted on DOS of course :) Nine -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGm85d1QuEJQQMVrgRApH5AJkBuciPOFi4f3HDtPhRjb9LECb8GQCeJXuX EavYwFckfz8WVSUbxyGst5M= =3HCF -END PGP SIGNATURE- - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Chaos in FG development [was: Bomb patch for vulcanb2]
On Saturday 14 July 2007 18:48, Melchior FRANZ wrote: * leee -- Saturday 14 July 2007: Perhaps FG has reached the point where it positively needs some sort of oversight management and planning, as seems to happen with many, if not most, large-scale Open-source projects e.g. Apache, Wine etc. I think that projects where this works always have a few sponsored (paid) developers. Of course, you can tell those on what to work. But you can't tell unpaid developers. What if some project manager says the next point on our plan is to beef up weather modeling -- do you think that Andy, Fred, Mathias, Maik, etc. will then all work on weather stuff? Even though they have no interest in that region (other than having it work nicely when they run fgfs themselves)? I have insight in a few F/OSS projects, and everywhere it's the developers who make their plans. Each on their own. Except paid developers, where it's sometimes the sponsor. I for one don't really have a TODO list, though I often say I'd put something there. :-) I decide on which things to work on next as I run into them. Segfaults are often a motivation to look into some code. Sometimes I need/want a feature and find that it doesn't work as I think it should, and work on that. Today I just thought that I'd like to do something nice, something with Nasal and placing models. (False alarm -- I haven't done anything. Well, not for FlightGear that is. But it's not too late ... :-) m. That's a good point about sponsored/paid developers. FG is the only F/OSS project I have actually had any form of active participation in so I don't know how many other F/OSS projects have sponsored/paid devs working for them and how that factor influences those projects. I am very aware too that I only worked on things that interested me - the 3d models animations, FDM configs and control systems but not cockpits:) So _if_ undirected development contributes to chaos I was certainly playing my part as well:) I'm not sure to what extent this may be a problem, if it is a problem at all, and if it is, what the answer may be. However, I can't shake off the feeling and impression that FG is is displaying some of the early signs of a project 'going wrong'. Perhaps this is just because, as I said, I haven't worked on any other F/OSS projects and I am not familiar enough with the normal F/OSS development path but the 30 years experience (I was 50 last week, so happy birthday to me:) I've had of working on managed projects are leaving uneasy about FG. Anyway, having raised the issue, I hope it will be in the minds of the people working on FG and will, perhaps, extend the context that people see themselves working in. LeeE - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Chaos in FG development [was: Bomb patch for vulcanb2]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 leee wrote: It is difficult to see a good answer to this issue. On the one hand, planning ahead and setting specific objectives for the FG developers to work towards would give known objectives and a clear development path but at the same time would constrain developers to working on what the plan requires, which may not be what the individuals concerned are interested in. On the other hand, if FG development carries on as it is now, with developers able to follow any line of development they find interesting there will be many new valuable developments but it will continue to be unpredictable and chaotic. The largest open source project with thousands of developers, namely the Linux kernel itself does not have the slightest idea of a road map, even though most of the developers are in fact paid to work on it. And it works pretty well. Perhaps FG has reached the point where it positively needs some sort of oversight management and planning, as seems to happen with many, if not most, large-scale Open-source projects e.g. Apache, Wine etc. I'm not aware of any oversight planning or road map for wine, but I could just have overlooked it as I follow the development only as an interested user. Nine -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGmmme1QuEJQQMVrgRAksWAJ9B6FGswLFYcgUAjhypIAVpc2BuVACghq0x 0chPghVnshiBLzDDTDHl44k= =dnai -END PGP SIGNATURE- - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Chaos in FG development [was: Bomb patch for vulcanb2]
* Stefan Seifert -- Sunday 15 July 2007: The largest open source project with thousands of developers, namely the Linux kernel itself does not have the slightest idea of a road map, even though most of the developers are in fact paid to work on it. And it works pretty well. Exactly. I'm not so much a leader, I'm more of a shepherd. Now all the kernel developers will read that and say, He's comparing us to sheep. It's more like herding cats. -- Linus TORVALDS m. :-) - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Chaos in FG development [was: Bomb patch for vulcanb2]
On 7/15/07, Melchior FRANZ [EMAIL PROTECTED] wrote: * Stefan Seifert -- Sunday 15 July 2007: The largest open source project with thousands of developers, namely the Linux kernel itself does not have the slightest idea of a road map, even though most of the developers are in fact paid to work on it. And it works pretty well. Exactly. I'm not so much a leader, I'm more of a shepherd. Now all the kernel developers will read that and say, He's comparing us to sheep. It's more like herding cats. -- Linus TORVALDS Which brings me to a thought I had the other day. I often hear that's not my area, I don't want to step on so-and-so's toes from committers, or I'm waiting for so-and-so to comment on it. Sometimes so-and-so says nothing (maybe he's busy, maybe he missed it, maybe he had nothing to add) and things fall on the floor. In any case, it seems that it would be in all cases more efficient to go straight to the person in charge of the area of the code in question when preparing patches. I think FlightGear could do well with a MAINTAINERS file, like what the kernel has. So if John Q. Newbie is preparing a patch to weather, or radios, or gui, or whatever - he'll know who to consult and approach for the best improvement of the project. There is AUTHORS, which points to Thanks, which was last updated in 2005 and isn't well-suited for the purpose anyway, and I don't see anything else. I could easily have missed something like this, and if it exists already I'd love to know where it is. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Chaos in FG development [was: Bomb patch for vulcanb2]
* leee -- Saturday 14 July 2007: Perhaps FG has reached the point where it positively needs some sort of oversight management and planning, as seems to happen with many, if not most, large-scale Open-source projects e.g. Apache, Wine etc. I think that projects where this works always have a few sponsored (paid) developers. Of course, you can tell those on what to work. But you can't tell unpaid developers. What if some project manager says the next point on our plan is to beef up weather modeling -- do you think that Andy, Fred, Mathias, Maik, etc. will then all work on weather stuff? Even though they have no interest in that region (other than having it work nicely when they run fgfs themselves)? I have insight in a few F/OSS projects, and everywhere it's the developers who make their plans. Each on their own. Except paid developers, where it's sometimes the sponsor. I for one don't really have a TODO list, though I often say I'd put something there. :-) I decide on which things to work on next as I run into them. Segfaults are often a motivation to look into some code. Sometimes I need/want a feature and find that it doesn't work as I think it should, and work on that. Today I just thought that I'd like to do something nice, something with Nasal and placing models. (False alarm -- I haven't done anything. Well, not for FlightGear that is. But it's not too late ... :-) m. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Chaos in FG development [was: Bomb patch for vulcanb2]
Well defining ranges of reserved attachable variables and hooks would help to keep things backward compatable. Define chunks of variables in chunks of 50 (allways define more than you think you need for the future.) To much MANAGEMENT though will slow down contributions. On Sat, 14 Jul 2007 10:00 am, leee wrote: On Friday 13 July 2007 21:39, Melchior FRANZ wrote: [snip...] Coders are all the time adding new code, which can sometimes be chaotic. On the other hand, coders are also fixing chaotic code. All the time. Yes, there is some, but as long as you aren't actually working on the code, it shouldn't really concern you much. Are you aware of people who were scared away by the chaos, and decided not to contribute because of it? Which files or subsystems do you find most chaotic? I'm sure we can work on those. m. I think this is a very important observation by Melchior, although he and I might disagree on both the degree and effects of the 'chaos' in FG :) The earliest FG mailing list posts I have archived date from late 2002 so I reckon that is when I started contributing to FG and since then there has been a huge amount of development in FG, all to it's benefit and leading to a much more capable and effective package. However, as well as the software developers who are developing the FG platform/framework itself there are those who use and develop _for_ the FG platform, for example aircraft developers who make aircraft for FG and development research projects that use FG as their environmental framework. For this group of people/users I would say that the FG platform has become much more chaotic and difficult to use or to develop for unless they 'freeze' a local version and don't try to keep track of FG development after the freeze. Doing this though, will make their work incompatible with future versions of FG, which cannot be a good thing. It is difficult to see a good answer to this issue. On the one hand, planning ahead and setting specific objectives for the FG developers to work towards would give known objectives and a clear development path but at the same time would constrain developers to working on what the plan requires, which may not be what the individuals concerned are interested in. On the other hand, if FG development carries on as it is now, with developers able to follow any line of development they find interesting there will be many new valuable developments but it will continue to be unpredictable and chaotic. Perhaps FG has reached the point where it positively needs some sort of oversight management and planning, as seems to happen with many, if not most, large-scale Open-source projects e.g. Apache, Wine etc. I personally hate to be even a little bit critical of FG and it's community of developers because FG is a tremendous achievement by a lot of very skilled and talented individuals but it's because I do care about FG that I feel obliged to comment when I believe I see something that could harm the project. LeeE - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel www.GlobalBoiling.com for daily images about hurricanes, globalwarming and the melting poles. www.ElectricQuakes.com daily solar and earthquake images. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
