Boost the funding... 0.4 release

[cruonit]

Just hypothetically:

I know it's not posible that one developer finishes the explorer-new in 35-40 days - a reactos 0.4 blocker but that would be a funding booster for ReactOS CE.
If reactos manages to get close to 50.000 in the next 40 days or with the 0.4 release it could get a promotion inside "Trending now" category that could boost it over 50.000.

The question is are there other developers willing to boost the explorer-new in order to release ROS 0.4? still the question is can it be tested so quickly.

The deadlines are not real but if there where more developers(approx 4-5) maybe it could be done if there are no blockers but it's unreal

[DOSGuy]

Unfortunately, you can't casually estimate how many developers it would take to get something like this done. For one thing, each developer has different skills and experience with different parts of the code, so it's not the same as the classic "if 5 workers can move 10 crates in an hour, how many workers to does it take to move 200 crates in two hours?" scenario. There may not even be 4-5 developers who have the necessary experience. Also, five developers won't necessarily work five times as fast as one developer. They can't all be working on the same part of the code, so they have to efficiently divide the work between themselves, and inevitably some of those tasks will be completed faster than others, while other tasks will be stuck waiting for the other tasks. Throwing more manpower at a coding problem doesn't scale linearly; there are always diminishing results. Finally, no one can predict when they might hit a brick wall that just can't be easily overcome. It's quite possible that there's no amount of effort that can be thrown at explorer_new that would have it done before the IGG campaign ends. I'm sure every effort is already being made to have a 0.4 release as soon as possible.

[Webunny]

Just hypothetically:

I know it's not posible that one developer finishes the explorer-new in 35-40 days - a reactos 0.4 blocker but that would be a funding booster for ReactOS CE.
If reactos manages to get close to 50.000 in the next 40 days or with the 0.4 release it could get a promotion inside "Trending now" category that could boost it over 50.000.

The question is are there other developers willing to boost the explorer-new in order to release ROS 0.4? still the question is can it be tested so quickly.

The deadlines are not real but if there where more developers(approx 4-5) maybe it could be done if there are no blockers but it's unreal

Hmm. As far as I understood, 0.4 is NOT going to come out right after IGG finishes. Instead, they'll use the money TO finish it. Also, all the 'push your app' is pointing towards the fact that develeopment is continuing after the IGG.

So, as I see it, when IGG finishes (it does seem to slow down a bit lately, but then again; many already sponsored outside the IGG project, AND it was pretty short after the failed thorium-project, which no doubt affected it too), development is just going to go forward even more in earnest, and it could well be, it takes another 40 days after that until it comes out. Which means 80 days of development. Or more. Time enough to implement some new stuff. As for it being ready *beforehand*; that's unlikely.

It's fine enough if it is IN 0.4 as it comes out.

I personally will be satisfied (and I also think this are the minimum requirements for it going to a 'grand' new release of the 0.4) if it has:

- full USB support
- some extra general-purpose drivers (notably HD audio) that auto-work
- a new shell and GUI/icons/theme (something 'fresh')
- a 5 - 10% increase in Windows compatibility overall

[cruonit]

Unfortunately, you can't casually estimate how many developers it would take to get something like this done. For one thing, each developer has different skills and experience with different parts of the code, so it's not the same as the classic "if 5 workers can move 10 crates in an hour, how many workers to does it take to move 200 crates in two hours?" scenario. There may not even be 4-5 developers who have the necessary experience. Also, five developers won't necessarily work five times as fast as one developer. They can't all be working on the same part of the code, so they have to efficiently divide the work between themselves, and inevitably some of those tasks will be completed faster than others, while other tasks will be stuck waiting for the other tasks. Throwing more manpower at a coding problem doesn't scale linearly; there are always diminishing results. Finally, no one can predict when they might hit a brick wall that just can't be easily overcome. It's quite possible that there's no amount of effort that can be thrown at explorer_new that would have it done before the IGG campaign ends. I'm sure every effort is already being made to have a 0.4 release as soon as possible.

That's the reason people "invented" software engineering/project management. Sorry, 4-5 system programmers/expirienced winapi devs i meant existing reactos developers not new developers.

Finally, no one can predict when they might hit a brick wall that just can't be easily overcome.

>

The deadlines are not real but if there where more developers(approx 4-5) maybe it could be done if there are no blockers but it's unreal

i said this is only hipotetical


Maybe a similar event before the end of the campaign could boost the funding

[DOSGuy]

I'm just empathizing with the developers and thinking that they must be getting tired of people assuming that difficult things could be quickly achievable if only [insert arbitrary number] developers were to dedicate themselves to the task. I have to imagine that if something as important as explorer_new could be quickly completed if only 4-5 existing developers were to focus on it, they would do that. If they haven't done that, one or more of the following things is likely to be true:

1. There aren't 4-5 existing developers who have the necessary knowledge of the code
2. The aforementioned 4-5 existing developers exist but aren't available
3. The task simply can't be quickly completed by 4-5 (or perhaps any number of) developers

Regardless of #1 and 2, I suspect that #3 is true. I'm under the impression that the work necessary to get explorer_new working is among the least documented and least understood parts of Windows, and that the person who is contributing the most work to that effort at the moment has the best understanding of that functionality, not only among ROS developers but perhaps more than anyone in the entire world who has never seen a line of Microsoft code. It has to be remembered that Microsoft only publishes the portion of their API that developers need in order to develop programs for Windows. Microsoft never intended for third-party developers to offer alternatives to explorer.exe, so there is no documentation on how that stuff works. That's why ROS is in alpha stage after this many years of development, despite being able to incorporate the work already performed by the Wine team. No one who hasn't worked for Microsoft has a manual for any of this stuff, and the people who develop ReactOS are the most knowledgeable people in the entire world on some aspects of Windows' internal operation.

There's no question that development would accelerate if the existing developers could devote more time to their work on ROS by having paid contracts. It's not as clear that explorer_new, or any other component of ROS, could be developed more quickly if other developers were to divert from their current projects and focus on that component. If they aren't already the world's foremost expert on that Windows component -- as the person currently working on it probably is -- then there may be serious limits to their ability to contribute until they become the world's foremost expert on that component. Everyone is probably best to continue working on whatever it is that they have made themselves an expert on until such time as a paid contract affords them the luxury of taking the time to become an expert on something else.

Sorry for the long response. I know you posted a good faith suggestion, and I hope you take this as a good faith response. I want ReactOS to be done as much as anyone else, but I'm a programmer and I get tired of people thinking that what I do is easy and that a second person could join me and get my projects done twice as fast, so I suspect that ROS developers get tired of people suggesting simple solutions to speed up their work while they do things that no one has ever done before. Even for the generic stuff that I create at work, nobody on my team knows more about the project I'm working on than I do, and I can't just ask one of them to join my project in order to get it done twice as fast. To help me at all, they would first have to understand what I have done, and I would have to constantly stop working in order to explain what I'm doing and why. I use best practices to ensure that my code can be maintained after I'm gone, but to help me create the functionality that hasn't been developed yet, they need to code their solutions the same way that I'm coding my solutions, otherwise you get something like... well, Microsoft Windows, where things are coded and rules are applied inconsistently -- sometimes non-sensically, sometimes incomprehensibly, sometimes disastrously! Throwing more people at a project can speed up development, but not linearly, and the code quality can really suffer for it. If you have the resources of Microsoft, you can throw an unlimited number of people together to meet the deadline and Frankenstein together a passable program. When you have limited resources, sometimes its best to let a small number of people do it slowly but well, since you don't have the option of having a large number of people do it quickly but poorly.

[Webunny]

I'm just empathizing with the developers and thinking that they must be getting tired of people assuming that difficult things could be quickly achievable if only [insert arbitrary number] developers were to dedicate themselves to the task. I have to imagine that if something as important as explorer_new could be quickly completed if only 4-5 existing developers were to focus on it, they would do that. If they haven't done that, one or more of the following things is likely to be true:

1. There aren't 4-5 existing developers who have the necessary knowledge of the code
2. The aforementioned 4-5 existing developers exist but aren't available
3. The task simply can't be quickly completed by 4-5 (or perhaps any number of) developers

Regardless of #1 and 2, I suspect that #3 is true. I'm under the impression that the work necessary to get explorer_new working is among the least documented and least understood parts of Windows, and that the person who is contributing the most work to that effort at the moment has the best understanding of that functionality, not only among ROS developers but perhaps more than anyone in the entire world who has never seen a line of Microsoft code. It has to be remembered that Microsoft only publishes the portion of their API that developers need in order to develop programs for Windows. Microsoft never intended for third-party developers to offer alternatives to explorer.exe, so there is no documentation on how that stuff works. That's why ROS is in alpha stage after this many years of development, despite being able to incorporate the work already performed by the Wine team. No one who hasn't worked for Microsoft has a manual for any of this stuff, and the people who develop ReactOS are the most knowledgeable people in the entire world on some aspects of Windows' internal operation.

There's no question that development would accelerate if the existing developers could devote more time to their work on ROS by having paid contracts. It's not as clear that explorer_new, or any other component of ROS, could be developed more quickly if other developers were to divert from their current projects and focus on that component. If they aren't already the world's foremost expert on that Windows component -- as the person currently working on it probably is -- then there may be serious limits to their ability to contribute until they become the world's foremost expert on that component. Everyone is probably best to continue working on whatever it is that they have made themselves an expert on until such time as a paid contract affords them the luxury of taking the time to become an expert on something else.

Sorry for the long response. I know you posted a good faith suggestion, and I hope you take this as a good faith response. I want ReactOS to be done as much as anyone else, but I'm a programmer and I get tired of people thinking that what I do is easy and that a second person could join me and get my projects done twice as fast, so I suspect that ROS developers get tired of people suggesting simple solutions to speed up their work while they do things that no one has ever done before. Even for the generic stuff that I create at work, nobody on my team knows more about the project I'm working on than I do, and I can't just ask one of them to join my project in order to get it done twice as fast. To help me at all, they would first have to understand what I have done, and I would have to constantly stop working in order to explain what I'm doing and why. I use best practices to ensure that my code can be maintained after I'm gone, but to help me create the functionality that hasn't been developed yet, they need to code their solutions the same way that I'm coding my solutions, otherwise you get something like... well, Microsoft Windows, where things are coded and rules are applied inconsistently -- sometimes non-sensically, sometimes incomprehensibly, sometimes disastrously! Throwing more people at a project can speed up development, but not linearly, and the code quality can really suffer for it. If you have the resources of Microsoft, you can throw an unlimited number of people together to meet the deadline and Frankenstein together a passable program. When you have limited resources, sometimes its best to let a small number of people do it slowly but well, since you don't have the option of having a large number of people do it quickly but poorly.

That said, and wile I agree that 2 instead of 1 dev doesn't mean double as fast development, there is no doubt that more devs means faster development, generally speaking. Otherwise, all the talk about having too few resources, and all the pleas for helping in the code by those who can and joboffers for coding wouldn't make sense.

While it's unclear, thus, if 4 devs working on the shell or what not, could suddenly realise something in a fixed timespan (like, 40 days), that one wouldn't manage alone, it's also quite likely that it would speed up development considerably. There might be some overhead, but if you put it to extremes, and would say: well, money is no problem, I'll hire 1000 devs that focus on the shell development full time... I think it rather obvious that you would make giant leaps. Maybe, indeed, within 40 days. You'd have to manage them, but after all MS does it that way, and while not perfect, one can hardly deny it's doing things far faster than we (and I would say, also, better, in some aspects).

I therefore rather think the problem is #1 (or #2), rather than #3.With 4 devs more, it wouldn't maybe speed up 4 times, but an increase of 80-150% wouldn't be out of the ordinary.

[PurpleGurl]

I agree. While there is a diminishing returns effect (yes, I've read Mythical Man-Month), more devs will certainly help, even if the effect is not linear. On the shell work, I am sure 1-2 more devs would help speed it up nicely, since they might be more likely to find the major snags. But really, it seems we need more "forensic coders" the most. It seems research is one of the major things we need. If the current coders better understood how to reach the goals, it would make them more efficient.

[Frontier]

I thought I did quite a lot for the shell recently.

[gonzoMD]

I thought I did quite a lot for the shell recently.

You did, but the sad thing is that progress is only the visible things for the most people.
Drag'n'Drop is one of the most common used and needed things on windows so, thank you for your work!

[Webunny]

I thought I did quite a lot for the shell recently.

Your work is much appreciated, rest assured. The shell or explorer_new was only an example used by the parent poster and me or others to debate the reasoning how much progress one would make if the number of devs doubled or quadrupled.

I think oldman had some valid arguments, but only to a certain point. Maybe you, being busy in that area, could shed some more light on this. How much would progress continue / get faster, you think, if 4 other additional devs knowledgeable on the subject would join you? Would there be much overhead in developing explorer_new or the shell if you were with 4 working on it?

[justincase]

The shell or explorer_new was only an example

I think it was also a suggestion, as the work in shell-experiments (and other branches) while making notable visible progress, is not seen because being in a branch the ISOs are not readily available for newcomers to test (and see). The suggestion being that priority be put on making that branch ready for merging with trunk before the IndieGoGo Campaign ends, thus possibly giving more people some visible (to them) progress to help them to decide to fund it.
And while I think it's a great idea, as has been pointed out by others it's not feasible.

I thought I did quite a lot for the shell recently.

While this is visible progress, it's sort of ... hidden, visible progress in that one doesn't notice the (now working) functionality unless they happen to have tried it prior to it getting fixed (which many potential IGG funders haven't).
And while having this kind of feature working properly may not have the draw that merging in the shell-experiments branch (once ready) might, Not having it may push people away that would otherwise have funded, so beyond the normal thank you for the simple fact that you're working on ReactOS (thank you), Thank you for working on the bugs that might make newcomers go 'ugh, I can't even [enter buggy functionality here]? what a piece of [REDACTED] I'm not giving these guys my money', etc., we need all you (and others) can give (thank you all ).

[DOSGuy]

That said, and wile I agree that 2 instead of 1 dev doesn't mean double as fast development, there is no doubt that more devs means faster development, generally speaking. Otherwise, all the talk about having too few resources, and all the pleas for helping in the code by those who can and joboffers for coding wouldn't make sense.

While it's unclear, thus, if 4 devs working on the shell or what not, could suddenly realise something in a fixed timespan (like, 40 days), that one wouldn't manage alone, it's also quite likely that it would speed up development considerably. There might be some overhead, but if you put it to extremes, and would say: well, money is no problem, I'll hire 1000 devs that focus on the shell development full time... I think it rather obvious that you would make giant leaps. Maybe, indeed, within 40 days. You'd have to manage them, but after all MS does it that way, and while not perfect, one can hardly deny it's doing things far faster than we (and I would say, also, better, in some aspects).

I therefore rather think the problem is #1 (or #2), rather than #3.With 4 devs more, it wouldn't maybe speed up 4 times, but an increase of 80-150% wouldn't be out of the ordinary.

I agree; more developers is definitely better. I'm just cautioning against thinking that the project's complex goals could be quickly accomplished by having a few more devs -- or even the entire dev team -- focusing on a given problem or component. The devs focus on their particular areas because they have made themselves experts in those areas. If they were to work on part of the code with which they have no experience, they will have to learn a lot about that area, so even if there are no baffling blockers (remember the MSHTML bug?), there's no guarantee that they can learn enough to contribute enough quickly enough to meet any deadline. That is, unless we had the resources to "hire 1000 devs that focus on the shell development full time", which we don't.

Yes, more developers would be beneficial. Just beware of thinking that arbitrary milestones can be quickly achieved by diverting devs, or any other [insert simple solution here].

[PurpleGurl]

I thought I did quite a lot for the shell recently.

You did, and it is much appreciated. I think I have my components mixed up. I was thinking about Gigahertz and the current obstacles.

I agree; more developers is definitely better. I'm just cautioning against thinking that the project's complex goals could be quickly accomplished by having a few more devs -- or even the entire dev team -- focusing on a given problem or component. The devs focus on their particular areas because they have made themselves experts in those areas. If they were to work on part of the code with which they have no experience, they will have to learn a lot about that area, so even if there are no baffling blockers (remember the MSHTML bug?), there's no guarantee that they can learn enough to contribute enough quickly enough to meet any deadline. That is, unless we had the resources to "hire 1000 devs that focus on the shell development full time", which we don't.

On the MSHTML bug, one of the issues was a lack of coordination of effort. Someone who is not a regular coder for ROS had found the solution. But the patch somehow got ignored. Then one of the heavy hitters (not sure if it was Ion or HBelusca) independently started to reach the same conclusion about the problem. Then the patch was rediscovered. There had been a number of changes by that point that the patch needed reworked if I remember right. So a new patch using that one as a guiding influence was created, and that addressed the issue. And despite the nickname given the bug, it wasn't in the MSHTML code (probably deeper down than that). If things had been more organized, it probably would have been discovered several months earlier.

So what do you do when people help or provide patches and they get misplaced and the patch provider gets miffed at the lack of response, and then the team stays stuck trying to solve a bug that someone already figured out? And no, opening the repository to more people won't help. In a project like ReactOS, you could have a few coding symbols in the wrong place by someone who is not the most familiar with the build, and it could result in months of downtime trying to figure out where the build broke.

You make good points in that if someone has more expertise in a needed area, you don't pull them off and put them where they have no clue to fix a pressing issue. Still, we need to find ways to get more coders who will be useful to us.

[vicmarcal]

Well, there are several ways to boost the 0.4 release one veing the IndieGoGo boosting.
Of course we can dream with 20 devs joining from nowhere...or...doing something.
Probably something important here is to think: How can I help with my current skills? instead thinking how Devs could boost it.
Because in your hands is the success or not of ReactOS really, in the mass hands, and not in the Dev's ones.
No.Really.
And I am not talking just about Donations to KS, but about "pressing your press".
All the local newspapers, online small and big media in your country, accepts Tips regarding News. They have in the footer a "contact" link to at least a form to send them a News tip. And the tip could he so basic as sending them the Youtube video link. Even just that is enough.
This is much more important than you tought because:
1)There is a big chance the Indiegogo is featured.
2)In case not, at least they will know about our existance. And if seceral tips reaches from several emails to the Newspaper, probably they will feature us.
Do we need Devs for it?Nope.
You can do it.
Right now German, Italian and Spanish plus some English are being contacted. But there are 1XX other countries, and you probably live in one of them.

[justincase]

And I am not talking just about Donations to KS, but about "pressing your press".
All the local newspapers, online small and big media in your country, accepts Tips regarding News. They have in the footer a "contact" link to at least a form to send them a News tip.

Hmmm, I remember having seen both pr@reactos.org & press@reactos.org mentioned in different places.
Now lets say someone who's sending a tip to a news site, newspaper or radio station might want to mention 'To contact the official ReactOS PR Team you can send an email to ...' which email address is more likely to elicit a quick response to their inquiries?