Both of those projects has divided work force dedicated to maintain an=
drive enhancements to defined goals.
- We are missing what we want to do (eg. roadmap, feature plan)
This is somehow intentional, because I believe that volunteers do only =
they want to do anyway. In fact, the TODO list in the wiki has several =
priority items, but they have been pending for a long, long time (e.g.=20
writing a manual).
That item has been in my mind too as people complain that there ain't
one, even the developer one would be useful. But even if there are items
in TODO list, people hesitate what to do about it. Some questions that
could arise: Who do they consult? is my contribution really wanted? Do I
waste my time by doing this? I could be interested in this task, but
there is a "task reservation name" there.
So perhaps it would be best to form some kind of organization that
defines the goals and then defines responsibilities and backups for
components and tries to drive targeting those goals. Those could be li=
though like internal maintainers for specific components. It could be
like bi-monthly meeting to tackle issues on horizon.
So you like formalism. I myself like a loose development model. If you =
many active developers, formalism works better, because they start to=20
conflict and consume most of the time for endless discussions, otherwis=
But, people appear and disappear frequently in GRUB. Do you really thin=
works with GRUB?
Here is another example:
Someone writes a large pile (or even a small change) of code that he/she
would like to get into GRUB. He/she just sends a patch to mailing list
(or to tracker) and feels happy that I have done something now. Even if
there are several developers that could understand the code, they do not
even look at that as it is not within their close interests, or they
might not have time. Or they feel that there is someone else with more
knowledge that should handle this. So no-one really makes any kind of
response as there is no "pressure". Thus time the person has spent doing
something is wasted. This again generates negative publicity...
Another related issue is copyright assignment to FSF that seems to
hinder also some people. But for that we can't really do much.
I am involved with GRUB for 10 years, but I sometimes disappear complet=
several months. Then, back again.
I think Pavel is also working on GRUB for nearly as long as me, but he =
from time to time. It looks nearly random to me.
Those scenarios also map to myself.
Robert seems to be relatively constant these days, but he apparently do=
have time to comment on all patches.
So, till now, "Do whatever you want to do when you feel that you want t=
been the most practical, and legwork has been finished by official=20
maintainers who have some formal responsibility (actually, official=20
maintainers have responsibility only for endorsing the GNU philosophy, =
they have done more than this).
Right. But if there is no other responsibility for anyone, you cannot
really ask people to follow any kind of design philosophy if there is
no-one watching the progress. If you give free permission to do what
ever you want, then you can pretty much expect that you get what ever
I have from time to time though about projects that I have followed,
what has failed those or what could be the problem why there is no real
progress. In my opinion most of those have failed because there is no
real guidance on what to do next. People just do and assume that other
people will do something until they get enough frustrated and make the
necessary change themselves. If this happens, then it certainly does not
feel like fun.
Projects with active leadership/management seem to flourish much better
than on projects that where open sourcing means that here is the code,
do what ever you like with it.
So... to answer your question about formal development, yes, I feel that
it could help here. A bit relaxed model perhaps would be best but there
should always be tasks in horizon that needs to be done. Even some kind
of dependency graph for those could be a good idea to concentrate task
that needs to be done first. If tasks are somewhat defined then it is
easy just to pick one and do that, it also helps on keeping track of the
progress. It needs management but for that I would say that bi-monthly
irc/skype/or whatever meeting would be useful for. Also if there are
some design issues that might need multiple people to decide what to do
(or they might even need a vote or alternative authority override).