Community contributions to core apps & features. (Was: Terminal for ASU)

Michele Renda michele.renda at gmail.com
Sat Jul 26 14:30:33 CEST 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This problem is common to all the process / firms: who must to take the
important design decision?

There can be two possibility:

A) Who code

B) Who doesn't code but can have a global vision of the project


To choose between these two alternatives is not easy. Who code know well
how it run, what the hardware can do.

Who don't code, may have a global vision of the project, he know which
are the objectives, deadlines, etc. etc.

I am a programmer: when I receive a work I receive the specification and
I must follow it. It happen that from time to time I think: but this is
a stupid request / non sense. But I have to follow.

According me the best solution is a between A and B. B know where to go,
and A know which is the better way of to take it.
So, on openmoko will be a very nice thing that on the morning they get a
very good coffe in a table and A and B, because A can do nothing without
B and B can do nothing without A.

Then there is the thirth element

C) The end users

The end user are who in the end will pay and will use the phone. Their
request are important but there are two big problems:

	1) Often C don't know how it is running
	2) All C's have different needs and different wishes. Is impossible to
have all the persons happy.

An example GTA3 must to have a camera? For me is NO, for another person
may be the same, but for another is very important to get it.
Who must to win?

So I think decisions must be taken by A union B reading from time to
time also what say C. A opensource project / phone DOESN'T mean a
democratic process.


In a future I hope that some persons will start to build a S.O. for
Openmoko but driven by a different organization.
This will let Openmoko to put all his resourses on the hardware part,
while the SOFTWARE part is managed my another organization (Like it
happen now with PC and OS)

But in every case, it is only a my idea :)

Regards
Michele Renda
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkiLGOEACgkQSIAU/I6SkT1xqQCghYBc12Os3BsskIRYxw3nyKRc
HuUAoIgu5kqrzuS1JfPV0pJjo+Ih5f0l
=78YY
-----END PGP SIGNATURE-----




More information about the community mailing list