[OSM-dev] lack of server coders (was: London Underground stations?)
immanuel.scholz at gmx.de
Tue Jul 4 12:19:03 BST 2006
Steve complained about the few coders interested in coding the server.
Lars replied (not to specific this, but in general):
> But if I'm the only one who feels like this, then this project is far
> smaller than it should be. And then we have to ask: Why is it still so
> small, why aren't we attracting more contributors? Why are newcomers
> turned away?
For me, I have to cleary say that the lack of testing and debugging
capabilities and in the server code keep me away. I tried several times to
change that but each time I got stopped by Steve thinking testing and
debugging is either just fine now or not that important.
To be more specific about my current problems:
1) I need a real database snapshot. Or a planet.osm containing enough
stuff in the area I want to develop. When Steve thinks privacy is a
problem, the author field can be randomized. However, I think now that
Steve's concern is much different than privacy but instead he does not
want to give out the data because someone else could "steal" his project.
If this is really the case, I am off to a more open team. To me, OSM is
about distributing the data and encourage people to do every possible
stuff with it, not to gather as much as possible and then provide the
loudest grumbler with some morsel of XML.
2) Debugging capabilities are important. If you never used a debugger
(except some hacked printf-statements), then I am not suprised that the
server code is in such terrible performance and design condition.
dev.openstreetmap.org is nice for integration testing but it is not a
server for development.
3) The setup-process of a development server was terrible, last time I
checked. Most projects achieve a "configure && make dev" or something like
that. The last time I checked for OSM, it was far from that away. Steve
said it improved and several people succeeded in setting up their home
server. I don't believe him.
4) The database layout and the access classes look really scary and
overbloated to me. Last time someone suggested a clean reimplementation,
Steve almost fall off his seat about this (not surprisingly, since it is
his code). But if I would have to work on the server code, a major
overlook would be the first thing to do. If Steve's attitude is to prevent
people from doing this, few server coder will join the team.
5) There is no coordinated deployment process. The code goes sometimes
magically from the subversion into the running server (usually by Steve).
Coders are not sure what version currently runs - if the subversion is
more current than the server code or the other way round. Although someone
(Christoph?) said before, that this is his usual experiences from real
life projects, I disagree. In all other project, at least the coders (or
the ones that should become coders) are perfectly informed what runs on
the server and most times they also knew when the next server update is
scheduled. I think this greatly helps when just playing around with the
code or when bug hunting a specific problem.
A failure in any of these five points is enough reason to me to not code
anything within the server's codebase. I like to help, but then something
must be changed in OSM.
More information about the dev