tangoGPS community development, patches (was: tangoGPS magnify patch)

Stephen Pape srpape at gmail.com
Mon Apr 12 20:36:38 CEST 2010

> I do not always have time to work on tangoGPS and still can do a
> constant flow of new features. You are a funny man - big scandale that
> not all my brain activity is monitorable :) I know that RMS would like
> to enclose all software developers in a gulag with constant thought
> monitoring - yeah! Any software thought must be freed at once :)

No one is asking you to dump every thought you have for public
viewing. I don't think a publicly viewable SVN server, so people have
some sense of what's going on, takes it to your extreme scenario. They
would, however, like to know if their patch was accepted, if there was
a problem with it, or if someone's working on a similar feature at the
same time.

> Just to mention it: the linux kernel had been developed for the first
> years purely based on tarballs and patches without any public
> distributed VCS and collaboration has worked without problems. Simply
> because in 1992 pretty much nobody had a 24/7 permanent online internet
> access.

Sure, that was fine way back then. Times have changed, and people do
have 24/7 permanent online internet access. You'll notice the kernel
developers shifted away from that development approach.

> A last word: the vast majority of the members of the Openmoko community
> are here for the opportunities that open hardware and open software
> offer. Hwoever a small fraction has a misunderstanding about free
> software. I have seriously received bizarre emails of people telling me
> what I have to do because I am a free software developer and as they
> don't know how to write software I have to do it for them.

This has nothing to do with people telling you what to do because they
can't write software.

I'm not saying you have to give up control and let people hijack the
direction you want to go in. I'm saying when someone takes the time
and energy required to write a patch, they should know if it's going
to be accepted or rejected without having to wait for the next
release. They should get a chance to clean it up if there's a problem.
There should be discussion so someone can ask if they should even
bother doing the work and get feedback.

Your current approach discourages anyone from contributing back to
you, and yet you discourage anyone from creating a fork. Have you seen
the people trying to help? Someone mentioned feeling like they're
trying to hit a moving target, while blindfolded, just to help out.

Forking is not a bad thing. In fact, sometimes forks end up being more
successful than the original project. Xorg from XFree86 ? How about
gcc? Apache, maybe?
I'd suggest you read this if you have a fear of forking
http://linuxmafia.com/faq/Licensing_and_Law/forking.html (WHY LINUX
WON'T FORK: And why being able to fork is still A Good Thing)

I tried to find something explaining how forking hurts open source
software, but I couldn't find any useful results with Google. If
someone feels they can do a better job, I'd encourage them to try


More information about the community mailing list