Firefox is a PIG on memory var: Respectful critic - thanks.

[Eric S. Johansson]

Art Alexion wrote:
> Eric S. Johansson wrote:
> 
...
>> boil down to "there's no effect of way of paying someone so they will
>> notice your problem and help you fix it".
> 
> Of course there is.  I know a lot of unemployed, underemployed or freelance
> developer who would love to get paid to address or fix your open source
> problem.

but that really doesn't solve the problem.  I'm not looking for anybody 
to dive into the code and have me pay them to learn it.  I want to pay 
for concrete knowledge.  If I want someone to just dive in, I just look 
in the mirror for someone who does good quality work that I can trust. 
When I get stuck, I want to pay someone who has more knowledge than I do.

> Try hiring someone to tweak Internet Explorer or MS Office code...

I wouldn't but I would hire someone to write plug-ins and live with the 
end result.  What's really disgusting is that there is more open 
knowledge about Microsoft plug-ins for Outlook or Explorer then there is 
for Firefox/Thunderbird.

[ side diversion: when I was looking to build plug-ins for Thunderbird 
to work with my antispam environment I was astounded by three things. 
Lack of knowledge current or otherwise, disorganization of knowledge, 
and complexity for something that should be relatively simple.

my expectation is that someone who is interested and moderately smart 
should be able to make the framework for a plug-in within four hours of 
picking up the manual.  Within six hours, they should know how to put a 
button on any aspect of the system.  Within eight hours, they should be 
able to couple to any external program.  It isn't happening.

To be fair, Outlook plug-ins take about three times as long as my 
expectation from what I can tell but the documentation is there if you 
are willing to read it.  For Thunderbird, it isn't.  It's missing the 
entire API applicants could and should use.  This whole layers upon 
layers upon layers of XML and cascading style sheets and other crap for 
the appearance is a huge barrier to entry especially for someone who 
just wants to get the job done and doesn't want to make a career out of 
plug-ins.]

>> Quite the problem.
> 
> I think confusing support -- as in how do I do this -- with development,
> improvement and security and bug fixes, is a mistake.  Apples and oranges.

we are very much in agreement on this point.  One of the challenges in a 
development organization is the effort required to retrofit security and 
bug fixes on to older versions of code.  In a previous life, I once had 
to make and test a security fix across seven versions of the operating 
system including two which no longer had any current knowledge in-house.

it sucked.

> Anyway, when was the last time you asked for and got good support from a
> commercial software company (unless you purchased some sort of premium
> support service)?  The support people generally know less than you do about
> their product, and can only answer questions you don't need to ask.

it depends on the company.  If it's a relatively small organization, I 
could support.  In a large organization, it's not so good and if it's 
ScanSoft, it's fucking miserable.  The last really sucks if you're 
handicapped like me and need to use speech recognition but that's 
another story.

close source parallels open source in many ways.  In a small 
organization support is good because the developers are close to the 
support line.  Many times they are brought in to provide support because 
they screwed up and the organization is small enough that this 
"punishment" can be inflicted on the developers.

larger organizations have enough politics to prevent just and equitable 
punishment for crappy software development.  The same happens with large 
open-source projects.  Developers tend to isolate themselves from the 
unwashed masses and let other people provide support.  Again, they 
escape divine retribution by being the gods themselves.

> I am sure you are correct here, but the same is just as true with small
> commercial projects.  In fact, I'd guess that most small commercial
> projects don't have the resources to ever seriously happen at all.

I hope not.  I have a small commercial project which I hope to make live 
in the next three to five weeks.

>> and with open source, only a few understand the code.  I think the real
>> difference is that with open source you get a chance at understanding
>> the code.  It's up to you to decide whether or not it's an itch you need
>> to scratch or can sit back and ignore.
> 
> No doubt true, but that is the beauty -- while you may not understand the
> code, the openness allows others who not only understand it, but coming
> from a fresh and different perspective than the original development team,
> may see things that the original developers overlooked.  That sort of peer
> review is totally inconsistent with the trade secrecy surrounding
> proprietary software.

I think we're mostly in agreement.  The only point I would dispute is 
that other developers coming in getting fresh and different 
perspectives.  Far too often I've seen code rewritten strictly because 
of an ego exercise replacing the original with something just as complex 
and messy but now it's the creation of the current egomaniac... I mean 
developer.

> 
> If there is anything that I have learned about software and cigars -- the
> addage "you get what you pay for" is rarely true.  Even when "the best
> things in life are[n't] free", they are often much cheaper than an inferior
> product.

:-)  there is nothing so expensive is a cheap lawyer...