Hey Joao!
You I think you touched some relevant points there. I will write one thing that I read about motivation and try to add some things to your
evolutionary design selection thought. Lets make this!
I've never been involved in any type of open source project so I can't really speak from experience,
but I've got the feeling that some projects end up not evolving very much because somehow people are not motivated.
In software, many times the motivation for starting an open source project is solving a personal problem. “Every good work of software starts by scratching a developers personal itch.” (from
http://catb.org/~esr/writings/cathedral-...ar/cathedral-bazaar/ via the book Producing Open Source Software – Karl Fogel) Karl Fogel adds that “ The essential condition is that the producers of the software have a direct interest in its success, because they use it themselves”. I was thinking that you have to give something back to the developer community so they can use it themselves. In the case of the e.Moped, in Version 0.1, we are starting by giving the developer community, access to geometrical data that developers would other wise have to build from scratch, sparing people time to focus on real innovation work. That is our "personal itch", in other words, we would like to have this geometric data ourselves, so we could be focusing on version 0.2 (for example).
I think that giving people the boundaries to design the moped have 2 advantages:
- I gives a good incentive to start thinking and, since it is a group challenge, it might have that competitive spark that makes us move forward.
That's true, by creating these “boundaries” you help people spot very quickly what are the present challenges of a project. You spare people the time to discover how and where to contribute.
I am discovering that it's not enough to say, that a project is open to contributions, the project initiators have to clearly point out how can someone contribute, how will these contributions be analysed and flow into the project. One way to do this is to have a clear Developer Guidelines Document, well visible on the project site. By the way, the e.Moped project is still missing that...
For the future, maybe a evolutionary selection would be interesting to arrive to the best result.
One would grab all the submitted designs and grab best characteristics of proposed geometry.
Then these best characteristics would be used to propose a new blueprint and the process would be started again.
after a couple of generations, the boundaries start being more defined and real engineering can begin.
As of your suggestion, I think it would be an amazing experiment. The program would have to recognize the “submitted designs” evaluate “user ratings”; “number of downloads”; “number of bugs” ;“number of comments” among other parameters to be defined and create an overview of the “design evolution tree”. Maybe users would play “god” an actively Mutate two design species into another! And the cycle of product development life begins again...did I go too far?
