OS Collaboration

[nekros]

Would you?

[01000101]

I've been there, done that, and watched it fail miserably.

It's not that it's a bad idea, it's just that people get distracted easily and will forget to follow the path laid before them. Also, different coding styles really makes things more difficult. Unless I saw a rock-solid-worth-doing design that was both innovative and unique, I probably wouldn't join it.

[nekros]

Basically, a very well developed design, well defined coding rules, etc.

[piranha]

I would consider it if there is a design that is good, and coding guidelines are solid...

-JL

[nekros]

First we have to collaborate on the design and coding rules.

[piranha]

Wouldnt that be done best over an IRC channel? That way people can talk directly?

-JL

[nekros]

I'm refering to this as ocop from now on (osdev.org collaborative os project), don't kill me it's just a codename. Channel is at freenode (#ocop).

[JackScott]

First we have to collaborate on the design and coding rules.

And that, my dear friend, is what will kill your project stone cold.

[Kevin]

No, this is actually not the worst problem. Set the rules from the very beginning and be strict on them. It doesn't matter too much which coding style you take, but it is important to define it. If you do that, it can work out.

Such a project has a different, but severe problem: Everyone already has his own OS he's working on. And this will stay on highest priority for most participants. This is at least my experience from the community OS at Lowlevel where we suffer from having too few really active developers.

[Combuster]

There are several beginner mistakes regarding group/community OSes. While some actually work, like Pedigree, most don't. A good amount has been mentioned before, but still:

Design:
1) There should be a clear design.
2) You can't design an OS with several people. The polder model is especially a Bad Idea.
3) A benevolent dictator is needed to enforce and maintain the design.

People:
4) You need pretty good in-depth knowledge to be able do kernel or driver development, even more when you do it as a team.
5) Designing a community OS should not be your first design.
6) Should feel personally responsible for the project to make progress.
7) People attract their kind to the project.
Bottom line here: newbie starts project, newbie attract newbies, project fails because nobody in the team has a clue.

[nekros]

I'm getting why this was not practical.... Oh well.

[Troy Martin]

Bottom line number two: Semi-advanced person starts project, project attracts more semi-advanced people, project fails because members work on their own OS instead and actually get somewhere with it.

[Combuster]

The difference is that with semi-advanced people, there's actually something you can do about it.

[Troy Martin]

True, but still, it will probably wither away and die within a few weeks if there aren't extremely advanced people heading up the project.

[Love4Boobies]

I can only imagine open source projects starting with one (or a few) developers that get along and get it to a level where it will attract other people as well. This also has the advantage of everyone knowking who's boss and there won't (or shouldn't) be much fight on the overall design. Of course, this is a simplified process; there could be several designers for different parts of the project, but the thing's gotta start somewhere. There might be exceptions where the whole community can start a project, although I've never actually heard of that.

As an aside, it would be pretty cool if we had some OSDev.org example OS that could be explained in detail on the wiki. It might even reduce the amount of questions asked on the forums since people are pretty lazy at googling. And if you say anything about increasing the rate of copy & paste developers... well... you can't do anything about those. They will probably never end up writing an OS anyway.

I just said it would be cool, not that it would actually work.