Retiring from uClibc development

Manuel Novoa III mjn3 at codepoet.org
Fri Mar 31 04:54:19 UTC 2006


Jeez... I couldn't let this one slide...

On Thu, Mar 30, 2006 at 01:43:09PM +0200, Natanael Copa wrote:
> First, a big thank you for making uClibc and for making it available to  
> the public. Its awesome!
> 
> On Thu, 30 Mar 2006 04:54:24 +0200, Manuel Novoa III <mjn3 at codepoet.org>  
> wrote:
> 
> >On the other hand, if you've got a bug report not specific to your  
> >branch, tell me and I'll fix it in my tree.
> ...
> >But I'm generally not going to make fixes available to our competitors  
> >before we actually roll them out ourselves.
> 
> So, there are contributors, "competitors", that fix things and send them  

contributer != competitor.  And in this context, I'm referring to
business competitors.

> to you, motivated by the thought that as many as possible should benefit  

There are many companies that have sent us bug reports over the years.
In some cases, they sent patches.  Occassionally, those patches even
worked.  But don't kid yourself.  They weren't being altruistic... they
wanted a fix in for their own use.  And most of these companies NEVER
contributed to the development of uClibc.  The number of companies that
have actually contributed in some meaningful way, be it patches,
contracts, etc. is probably under 10.

> from it. You grab those fixes put them in your own private space, keep  
> them there so no other can (easily) benefit from them until you do  
> yourself?

WHAT!  Any patches sent to the list are available to anyone.  The only
thing I "hold back" are things I write MYSELF on time PAID FOR BY MY
EMPLOYER!  When we release binaries, we'll release source.  This is
perfectly with rules of the (L)GPL and, given the contractual _and_
ethical constraints involved, how could I rightfully do otherwise!

> So while those (unpayed) contributors do what they can to help others  
> benefit from their work (by submitting fixes upstream instead of running  
> their own branches, fork or whatever), you do what you can to prevent, or  
> delay, others to benefit from it.

Do you have ANY knowledge of the histroy of uClibc?  I started working
on uClibc with Erik some time around November or December of 2000.
I probably wrote 20-25% of the libc code.  I wrote the original gcc
wrapper we used to use.  I did the original toolchain patch sets for
native <arch>-linux-uclibc support to replace the perl/sed hacks that
Erik originally put together to coopt the normal <arch>-linux support.
I can't even count how many people I've helped on the mailing list
or on irc over the years.  And while a lot of the code was contracted,
quite of bit of code and testing and all the user support was done on
my OWN time.

Furthermore, absolutely NONE of the stuff I've contributed to busybox was
under contract.  Why don't you take a look at the busybox AUTHORS file
and search through the mailing lists for some idea of my contributions
there.

In future, you should REALLY get your facts straight before going off
and insulting someone.

> I can understand that some people have their business to take care of, but  
> to me it seems like those "competitors" tries to help you, not fight you.  
> I can understand that people get frustrated.

You seem to be confused about what I mean by competitor.  In particular,
I'm referring to my employer's main business competitor that I know
uses uClibc in some products but has not (to my knowledge) made source
available for download.

> I'm not blaming anyone or trying to point out who is doing what wrong -  
> thats not interesting. I'm interested in the good things that you actually  
> do (i.e. uclibc)

There is nothing in the GPL or LGPL that says I have to release my fixes
unless/until I actually release something using them.  When we do one,
we'll do the other.  If you think I should do more out of the goodness
of my heart, a rather idealistic view which I _used_ to share, then let
me tell you a little story...

Three years ago, the woman I had been involved with for 6+ years
and who I had known for over 15 died of cancer.  Given all the time I
had put into supporting uClibc and busybox and all the time I had
put into answering questions on the mailing list and irc, I idealisticly
thought that users might be willing to make a donation in her memory
to a charitable cause.  In particular, see DEDICATION.mjn3 in uClibc 
and http://www.busybox.net/lists/busybox/2003-March/008103.html on
the busybox mailing list.  Want to guess what the response was?  A total
of 2 emails offering condolences and 1 person offering to make a donation.  
There was even on person who stated he wouldn't donate because he
"didn't believe in causes."

So... while I'll still take contracts, be it for pay or in return for
donations to hospice, don't expect me to spend much of my own time
handing out "free lunches" to the poor user "community" (HA!) that
slapped me in the face in spite of my past efforts on their behalf.

> I wonder what the possible alternatives are for a solution? I would love  
> to se PSM continue developing uclibc, since I believe thats something  
> everybody benefits from (sooner or later). There are people that  
> appreciate your work, Peter. Thanks!

I never said that much of the stuff psm's done isn't valuable.  What I
_did_ say is that the way he has been using uClibc tip is disruptive
for other developers.  He is perfectly welcome to work on his own
branch, as do the rest of us, and merge things into trunk as a logical
unit when stable.

> And I would love to see uclibc development move forward without being held  
> back of buildroot or any other specific build environment or distro,  

So would I.  In fact, I even want it to expand beyond linux and,
depending on how things work out, may start working on a port to
ecos later this year.

> without being held back for any specific company to release any product  
> (which higly depends on market timing etc etc) and without being held back  

Product releases are _real_ considerations, as is the cost of
development time.  Right now I'm fixing bugs/defects in uClibc
that were reported by coverity.  Any idea what it costs us to
license that?

> by any personal conflicts - but thats probably unrealistic.
> 
> Thats my $0.02 from an end user perspective.
> 
> PS. I'm not doing much myself to directly contribute to uclibc. I test and  
> report bugs to people who have enough knowledge to fix or submit proper  
> bugrports upstream. I do what I can. I dont have to clean up after others  
> while having a contractor on my neck, so those things are easy for me to  
> say.

So you end your post with a disclaimer that all this is completely
abstract to you and you have no real experience with the issues being
discussed in this thread.  Next time that happens, you might want to
consider other options than posting.

Manuel




More information about the uClibc mailing list