How can non-programmers create useful "metric" roadmaps?

[Witch]

INDEX
- Main Question
- Who am I?
- What's my agenda?
- Why not leave things to the project leader?
- EOT

Main Question
How can a non-programmer such as myself create a useful "metric" roadmap? (I shall try and elaborate things with the below explanatory sections.)

Well the roadmap examples I've seen isn't quite what I have in mind actually. I would personally replace the word roadmap with the word chart since what I want to produce uses graphics more than text. But I thought that people might get confused if I didn't say roadmap first.



Who am I?
Like this blog describes I'm sort of like a "non-programmer-manager" trying to manage programmers without knowing what goes on in a programmer's universe. Even worse I want to try ideas for a specific OS project without knowing how to create an OS or knowing how to do testing or how to contribute code to the SVN tree. To summarize I'm not a programmer of any sort. (sort of.)

http://brandygalos.blogspot.com/2007/01 ... g-big.html

When I was a test manager, almost without exception, I was managed by people who had no clue about

a) the purpose of test
b) what test managers and test teams could do for them and
c) when or why test needed any of their time, except for ship weeks.

I had to teach my bosses the answer to all three of those things, but it was often hard because they thought they had the answers.

The management team just wants some simple way to accurately know the status of the project. It’s not their desire for numbers that is wrong. In a void of anything else, they ask for what they think they want. It works out much better if the test team can supply them with the status numbers they really need before they think to ask for those other abominations.

What's my agenda?

Witch is trying to come up with a suitable business proposal for potentially interested corporate sponsors. To do this, he needs numbers on time lengths on similar projects, which would correlate to ROS' own time lengths if the devs (and several more?) were employed full-time.

Why not leave things to the project leader?
Just to make things clear in case some ReactOS users is reading this. I'm not trying to overthrow the current project leader or create mutiny and chaos. Why, because I can't even program a website. Because being a project leader requires a lot of understanding for the programmer's universe. I don't have that understanding, I don't like all the responsibilities that comes with the job, and I'm a very lazy person. (I don't even move if the sky would fall on earth, I'm that lazy.)

So why not leave the creation of my chart to the all-knowing project leader?

1. He's too busy with important tasks than wasting time on this matter.
2. I want to try this "thing" since nobody else seems to care, maybe because of lack of manpower.
3. Because in order to persuade sponsors a non-programmer "metric" like roadmap needs to be created.



EOT
Hope this clarified what I'm looking for and where I come from. If I confused things too much then I would gladly answer followup questions, because it will help the cause.

[kmcguire]

y

How can a non-programmer such as myself create a useful "metric" roadmap? (I shall try and elaborate things with the below explanatory sections.)

Well the roadmap examples I've seen isn't quite what I have in mind actually. I would personally replace the word roadmap with the word chart since what I want to produce uses graphics more than text. But I thought that people might get confused if I didn't say roadmap first.

You need metric information about existing operating system development projects on individual points, components, or checkpoints. In that case you could in theory create a roadmap that may very well model the metric close enough to be suitable.

Maybe some people will post their age, how long it took them to complete certain parts of their operating system (total working hours), and their level of education when working on this part. Which could be used to compute a rough metric for each node in your graph (roadmap). You also need to know what nodes are going to be in the graph, but I suppose if it was easy then everyone would be doing it this way.

[stephenj]

Witch, the important thing you have seemed to overlook is that programmers rarely subject themselves to that kind of software engineering unless they are being paid for it. It isn't fun, and it doesn't accomplish much more than serving as a contract between two parties (which is why it is useful). But if you are bringing money to the table, don't expect anyone to do anything until they have said money in their hands (until then they'll see you as a Nigerian Prince with an "amazing deal"). Even after money has changed hands, you'd probably be viewed as a pointy-haired boss. I know I've worked for non-programmers before, and I wouldn't recommend it to other programmers (for any major projects anyway).

This roadmap is what they currently have, and (I'll bet) are happy with. They also have a page telling you what they would like to build if only they had the time/money (the money probably allows them to take time off work). Notice that the only two with filled in costs are 1000 and 2500 Euros.

What terms will come with the money? Will they be able to release the code under one of the project's standard licenses (GPL, LGPL, BSD)? If not, you may have to pay them a lot, assuming they would accept any amount.

And to answer the question of "non-programmers creating useful metrics." Usually, metrics made by non-programmers are determined by taking previously acquired metrics made in a similar situation, and applying/adjusting them to the current project. Which would be very difficult in this case (I'm only aware of one company that has created a Windows-like operating system, and their metrics would not be useful even if you could get them). You could look at operating systems in general, but then accuracy would be a problem.

The only real option would be asking the ReactOS developers how long it would take for them to do X given 8 hours / day and Y team members (you can't expect anyone to work more than 8 hours/day, even if they probably will). But don't be surprised if they come back at you and say "I don't know, I haven't done it before."

[Witch]

It doesn't look like I confused people too much, so I'm going to drag you guys deeper down the ocean with me where the core of my true question is located.

One metric number is flat but behind that one metric number lurks one or many multidimensional stories.
I kind of embedded 1 years amount of different multidimensional stories into one flat general question. I wanted to dip my toes into the waters before I asked too many stupid questions all at once. Now I know I reached the right number so I will try to ask more accurate stupid questions. Buckle up, here I go!

How can a non-programmer such as myself create a useful "metric" roadmap?

How much Time did it take to create Windows, Debian, Mac OS? - reference
I once asked on ReactOS forum if you could make a chart, timeline, roadmap, or whatever you want to call it. In order to help non-programmer eyes see the BIG picture. Thus making it easier to persuade donators to inject money in a more stable manner, and not like a roller coaster curve.

The sum of that thread is something like this:

• Different people / organizations will never agree. They will agree on some details and highly disagree on others.
• The difficulty is probably because different projects have different objectives.

«To create a general-purpose kernel suitable for the GNU operating system, which is viable for everyday use, and gives users and programs as much control over their computing environment as possible.» — GNU Hurd.

«To develop a quality operating system that is compatible with applications and drivers written for the Microsoft Windows NT family of operating systems.» — ReactOS.

So I tried to put different OS timelines beside eachother in order to tell non-programmers a story about how much longer it might take before ReactOS would reach beta and stable stages. But it seems like that isn't such a good idea.
Oh, another thing according to somebodies I should ask architects and not developers. So I wanted to see what your thoughts might be regarding this question, if it differs much from the developers?



I have more things I want to show and ask you architect people but perhaps one step at a time is best. Before we reach the core of my true question.

[Brynet-Inc]

Colours are against forum rules Witch.

http://forum.osdev.org/viewtopic.php?f=1&t=16944

Personally I think it is pointless to attempt to lead a project you know nothing about, or fully comprehend.. are you even affiliated with the ReactOS project? or just an outside spectator thinking you can do a better job?

Either way, I don't see how this is relevant on these forums.

[Mark139]

If you want to know the amount of resurces (time & money) needed to develop a commercial OS, just go and read about MS or Apple and the number of employees they have.

[Witch]

If you want to know the amount of resurces (time & money) needed to develop a commercial OS, just go and read about MS or Apple and the number of employees they have.

According to Z98 a ReactOS release engineer I can't do it like that.
reference

If you're trying to use the development timelines of other OSes as a guideline for ROS', don't bother. It doesn't work that way. This project is operating under different constraints than others and will operate under its own schedule, so what is "reasonable" for something like Windows or one of the Linux distros or even Mac OS X does not provide any guidance as to what stage ROS is at or how much longer you need to wait until it is usable.

And the ReactOS ohloh Cocomo isn't helpful to me either. Nor is it any helpful for me comparing Cocomos between different OS projects.
http://www.ohloh.net/p/reactos/widgets

Personally I think it is pointless to attempt to lead a project you know nothing about, or fully comprehend.. are you even affiliated with the ReactOS project? or just an outside spectator thinking you can do a better job?

Either way, I don't see how this is relevant on these forums.

Sorry I didn't know about the color thing, other forums usually let me do it like it was 1999. So it kind of runs on automatic with me. It won't happen again I hope.

• Officially affiliated no.
• Mostly an outside spectator with an itch for a specific spot that they seemed to have neglected.
• Do a better job as a whole no.
• Do a better job for that specific itch yes.
• Attempt to lead the project no.

So I thought it would be best to slow play things but since it already looks like things are turning sour. I just put all the cards on the table and see what happens.

My itch
So I basically think that ReactOS is bad at the donation department. I made suggestions to them they did it but things still wasn't as good as I initially thought. So I started to dig into things myself since it works faster than trying to bug and beg people. I think I already have 90% of the jig-saw-puzzles for the perfect formula

The missing 10% jig-saw-piece is making a map of ReactOS progress situation. I'm not sure how to do this part correctly. So I wanted to check with you architect people for some suggestions.

I want to make a LEGO map saying which pieces is done (alpha, beta, stable) and which pieces isn't done. Where the intended audience is for non-programmers the donors.

Macro metric = Sloppy estimates for non-programmers.
Micro metric = Precise quantification for project leaders, architects and developers.

ReactOS architecture looks something like this but I'm not sure how to define and count the pieces using the Macro metric measurement? Can you help push me in the right direction?
I was recommended the book Operating System Concepts I bought the 8th edition of it just for this itch but it didn't help me much.

[stephenj]

Before I say anything more, I'd like to commend you for doing your homework. After reading through the links it appears that you are trying your best to solve a problem. That being said, I'm not sure if you understand what you are reading well enough, yet. For example, the manager link you posted earlier refers to how a test-manager should "manage" (think social engineering) their manager. Which isn't applicable in this situation. For a (somewhat theoretical) background of how open source works from a project prespective, I'd recommend reading The Cathedral and the Bazaar, Homesteading the Noosphere, and The Magic Cauldron by Eric Raymond.

What you might want to try, is to organize a hackathon. OpenBSD has claimed good results from these events.

The part of your business proposal that I have yet to see is a definition of what is going to be accomplished by the team hired. Furthermore, if I care enough about open source not to use Microsoft, why wouldn't I support Linux development? Even if I wanted Windows compatibility, I'd still probably donate to WINE before ReactOS. You need to articulate why I would want to donate to this cause. The closest I've read is "Why ReactOS" but the arguments are about a theoretical future version with near-100% compatibility, not the OS I could download now. I say this as someone who will donate money if asked by the right groups (I donated to OpenBSD last week, for example, because openssh kicks @$$). Come to think about it, if WINE put out a call for donations, I'd probably donate because I use their software from time to time to play Warcraft III and Starcraft.

[kmcguire]

So I basically think that ReactOS is bad at the donation department. I made suggestions to them they did it but things still wasn't as good as I initially thought. So I started to dig into things myself since it works faster than trying to bug and beg people. I think I already have 90% of the jig-saw-puzzles for the perfect formula

The missing 10% jig-saw-piece is making a map of ReactOS progress situation. I'm not sure how to do this part correctly. So I wanted to check with you architect people for some suggestions.

I want to make a LEGO map saying which pieces is done (alpha, beta, stable) and which pieces isn't done. Where the intended audience is for non-programmers the donors.

Macro metric = Sloppy estimates for non-programmers.
Micro metric = Precise quantification for project leaders, architects and developers.

ReactOS architecture looks something like this but I'm not sure how to define and count the pieces using the Macro metric measurement? Can you help push me in the right direction?
I was recommended the book Operating System Concepts I bought the 8th edition of it just for this itch but it didn't help me much.

Maybe you should somewhere write something to scan for:

1. bug submits
2. mailing list for patches
3. scanning different between commits to the source code

And, by looking at the entire project on a file by file basis then grouping the files into certain components or systems you can determine a rough state of alpha, beta, or stable. You might have to do some hand work to keep the system looking good but it might just produce some useful information.

You would want to create the actual lego pieces and just map the values to each piece from the scans.

[Craze Frog]

So I basically think that ReactOS is bad at the donation department.

No, ReactOS is bad straight through. It will never be ready for serious use, just forget it.

[gravaera]

QFT at the post above me.

[Witch]

Thanks for all the tips and reading material it will keep me busy for a while.

So I basically think that ReactOS is bad at the donation department.

No, ReactOS is bad straight through. It will never be ready for serious use, just forget it.

Bad how exactly, could you elaborate a little? I've heard rumours about there being nobody left who can program and deliver new driver codes anymore at ROS. But that's a lack of manpower problem it can be fixed.

So what kind of bad are you refering to exactly?

[stephenj]

So what kind of bad are you refering to exactly?

From the ReactOS site: ReactOS is in alpha stage and not recommended for everyday use. Many applications do not work (correctly) because many API calls simply haven't been implemented yet.

It isn't that ReactOS is a bad idea, it just isn't ready for prime-time. And it is hard to raise money for something that isn't ready. Again, the allure of ReactOS is a Windows replacement, but it isn't ready to replace Windows yet.

[Witch]

ic, you mean that kind of bad. Well some people need to sacrifice themselves like G-zeus first and do the dirty work before it can blossom into beta or stable.
If nobody takes care of the dirty work today then it will never reach prime-time. You just need a lot of patience and stubbornness.

Regarding the money issue. Once I find the truth about the holy grail (progression map), then I believe a lot of problems will solve themselves automatically with little effort.

By the way stephenj I'm reading Homesteading and I like this chapter in particular it's great
Gift Outcompetes Exchange

Indeed, it seems the prescription for highest software productivity is almost a Zen paradox; if you want the most efficient production, you must give up trying to make programmers produce.

Handle their subsistence, give them their heads, and forget about deadlines. To a conventional manager this sounds crazily indulgent and doomed—but it is exactly the recipe with which the open-source culture is now clobbering its competition.

[js]

I know this post is rather old, but the tool I suggest (Evidence Based Sheduling) can help others too.

@Witch : You might want to use Evidence Based Scheduling (EBS), see here for a description : http://www.joelonsoftware.com/items/2007/10/26.html .

The bottom-line idea is that you get programmers to say how much time they expect to spend on each task they do, and then, comparing that with how much time it actually took, you "guess" the time that still-to-do tasks will need.

This would give you an insight of how much time some tasks will need.

As for the complete road-map, like someone suggested, dive into their code-source repository, and identify what parts are done, and what parts aren't.

To know what's left to do, look at how much of the windows API isn't implemented. As they'll have to fully implement it some day or the other, you can guess current progress.

If you wish to attract big donors (companies, etc.), you could look for companies that will need to run their in-house program (accounting, etc.) on a large number of computers, in the future, and show them that if they donated enough to ROS, they wouldn't have to buy the window$ licences. But it'll be hard to find such companies I expect.

Good luck.