Re: Itching and scratching (Re: source mgt. requirements solicitation)

Re: Itching and scratching (Re: source mgt. requirements solicitation)

[Robert Dewar]

> Speaking more generally, the folks that get paid to do free software
> are the ones who are solving the problems of people with the money.
> It's up to us to be clever enough to figure out to solve the specific
> problems in a way that improves architecture and infrastructure.
> That was a key but underappreciated aspect of Cygnus' development
> contracts; we would always try to go after projects that included
> infrastructure improvement, but if necessary we would do something
> that was random but lucrative and use the profits to pay for
> generic work.

For the record, this is very similar to ACT's approach to development
contracts.

Re: source mgt. requirements solicitation

[Bruce Stephens]

Linus Torvalds <torvalds@transmeta.com> writes:

[...]

> That is obviously also why the kernel ends up being a lot of lines of
> code. I think it's about an order of magnitude bigger in size than all of
> gcc - not because it is an order of magnitude more complex, obviously, but
> simply because it has many more parts to it. And that directly translates
> to more pieces that people can cut their teeth on.

The gcc tree I have seems to have 4145483 lines, whereas the 2.4.20
kernel seems to have 4841227 lines.  (Not lines of code; this includes
all files in the unbuilt tree (including CVS directories for gcc,
although this is probably trivial), and it includes comments and files
which are not code.  In the gcc case, it may include some generated
files; I'm not sure how Ada builds nowadays.)

Excluding the gcc testsuites, gcc has 3848080 lines.  So gcc (the
whole of gcc, with all its languages) seems to be a bit smaller than
the kernel, but probably not by an order of magnitude.

This is reenforced by "du -s": the gcc tree takes up 187144K, the
kernel takes up 170676K.  None of this is particularly precise,
obviously, but it points to the two projects (with all their combined
bits) being not too dissimilar in size.  Which is a possibly
interesting coincidence.  (The 2.5 kernel may be much bigger; I
haven't looked.  The tarballs don't look *that* much bigger, however.)

[...]

Re: source mgt. requirements solicitation

[Linus Torvalds]

On Mon, 16 Dec 2002, Bruce Stephens wrote:
>
> The gcc tree I have seems to have 4145483 lines

Hmm, might be my mistake. I only have an old and possibly pared-down tree
online. However, I also counted lines differently: I only counted *.[chS]
files, and you may have counted everything (the gcc changelogs and .texi
files in particular are _huge_ if you have a full complement of them
there).

What does "find . -name '*.[chS]' | xargs cat | wc" say?

(But you're right - I should _at_least_ count the .md files too, so my
count was at least as bogus as I suspect yours was)

			Linus

Re: source mgt. requirements solicitation

[Diego Novillo]

On Sun, 15 Dec 2002, Linus Torvalds wrote:

> On Mon, 16 Dec 2002, Bruce Stephens wrote:
> >
> > The gcc tree I have seems to have 4145483 lines
> 
> Hmm, might be my mistake. I only have an old and possibly pared-down tree
> online. However, I also counted lines differently: I only counted *.[chS]
> files, and you may have counted everything (the gcc changelogs and .texi
> files in particular are _huge_ if you have a full complement of them
> there).
> 
Output of sloccount on a relatively recent snapshot:

-----------------------------------------------------------------------------
SLOC    Directory       SLOC-by-Language (Sorted)
1274221 gcc             ansic=839349,ada=298101,cpp=73596,yacc=23251,asm=20244,
                        fortran=6934,exp=4706,sh=4430,objc=2751,lex=559,perl=189,awk=111
225571  libjava         java=131300,cpp=65054,ansic=27198,exp=1213,perl=782,
                        awk=24
67452   libstdc++-v3    cpp=49425,ansic=17270,sh=525,exp=193,awk=39
34729   boehm-gc        ansic=25682,sh=7631,cpp=972,asm=444
21798   libiberty       ansic=21495,perl=283,sed=20
11657   top_dir         sh=11657
10376   libbanshee      ansic=10376
10358   libf2c          ansic=10037,fortran=321
9581    zlib            ansic=8309,asm=712,cpp=560
8904    libffi          ansic=5545,asm=3359
8002    libobjc         ansic=7233,objc=397,cpp=372
3721    contrib         cpp=2306,sh=935,perl=324,awk=67,lisp=59,ansic=30
3074    libmudflap      ansic=3074
2506    fastjar         ansic=2325,sh=181
1463    include         ansic=1432,cpp=31
667     maintainer-scripts sh=667
0       config          (none)
0       CVS             (none)
0       INSTALL         (none)


Totals grouped by language (dominant language first):
ansic:       979355 (57.81%)
ada:         298101 (17.60%)
cpp:         192316 (11.35%)
java:        131300 (7.75%)
sh:           26026 (1.54%)
asm:          24759 (1.46%)
yacc:         23251 (1.37%)
fortran:       7255 (0.43%)
exp:           6112 (0.36%)
objc:          3148 (0.19%)
perl:          1578 (0.09%)
lex:            559 (0.03%)
awk:            241 (0.01%)
lisp:            59 (0.00%)
sed:             20 (0.00%)


Total Physical Source Lines of Code (SLOC)                = 1,694,080
Development Effort Estimate, Person-Years (Person-Months) = 491.37 (5,896.47)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months)                         = 5.64 (67.73)
 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  = 87.06
Total Estimated Cost to Develop                           = $ 66,377,705
 (average salary = $56,286/year, overhead = 2.40).
SLOCCount is Open Source Software/Free Software, licensed under the FSF GPL.
Please credit this data as "generated using 'SLOCCount' by David A. Wheeler."
-----------------------------------------------------------------------------


Diego.

Re: source mgt. requirements solicitation

[Pop Sébastian]

For comparison I've ran sloccount on LK:

$ sloccount ./linux-2.5.52
[...]

SLOC    Directory       SLOC-by-Language (Sorted)
1664092 drivers         ansic=1659643,asm=1949,yacc=1177,perl=813,lex=352,
                        sh=158
678895  arch            ansic=507796,asm=170311,sh=624,awk=119,perl=45
365490  include         ansic=364696,cpp=794
340797  fs              ansic=340797
261122  sound           ansic=260940,asm=182
193052  net             ansic=193052
14814   kernel          ansic=14814
13523   mm              ansic=13523
11086   scripts         ansic=6830,perl=1339,cpp=1218,yacc=531,tcl=509,lex=359,
                        sh=285,awk=15
6988    crypto          ansic=6988
6083    lib             ansic=6083
2740    ipc             ansic=2740
1787    init            ansic=1787
1748    Documentation   sh=898,ansic=567,lisp=218,perl=65
1081    security        ansic=1081
119     usr             ansic=119
0       top_dir         (none)


Totals grouped by language (dominant language first):
ansic:      3381456 (94.89%)
asm:         172442 (4.84%)
perl:          2262 (0.06%)
cpp:           2012 (0.06%)
sh:            1965 (0.06%)
yacc:          1708 (0.05%)
lex:            711 (0.02%)
tcl:            509 (0.01%)
lisp:           218 (0.01%)
awk:            134 (0.00%)




Total Physical Source Lines of Code (SLOC)                = 3,563,417
Development Effort Estimate, Person-Years (Person-Months) = 1,072.73 (12,872.75)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months)                         = 7.59 (91.12)
 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  = 141.27
Total Estimated Cost to Develop                           = $ 144,911,083
 (average salary = $56,286/year, overhead = 2.40).
SLOCCount is Open Source Software/Free Software, licensed under the FSF GPL.
Please credit this data as "generated using 'SLOCCount' by David A. Wheeler."

Re: source mgt. requirements solicitation

[Tom Lord]

	GCC: 

	Total Estimated Cost to Develop 	= $ 66,377,705

	LK:

	Total Estimated Cost to Develop 	= $ 144,911,083


and:

	(average salary = $56,286/year, overhead = 2.40).


(That's an appallingly low average salary, btw., and a needlessly
large overhead.  If we're thinking of a nearly 20 year average, maybe
it's not _too_ badly removed from reality, but it's not a realistic
basis for planning moving forward.)

Someone did a sloccount run on a bunch of my 1-man-effort software,
developed over about 10 calendar years, and the person-years count was
surprisingly accurate.

In general, there is something of a business crisis in the free
software world.  It's particularly noticable around businesses based
on linux distributions.

Those distributions represent a huge amount of unpaid work.
Businesses using them got some free help bootstrapping themselves into
now favorable positions.  So, not only did they get the unpaid work
for free (as in beer), they traded that for favorable market positions
that raise the barrier of entry to new competitors.  While in theory
"anyone" can start selling their own distro, in reality, there's only
a few established companies and investors with deep pockets who have
any chance in this area.

So what's the crisis?  Well, those freeloaders aren't exactly being
agressive about figuring out how to sustain the free software movement
with R&D investment.  Companies spend a little on public projects,
sure, but you can count the number of employees participating,
industry wide, on the fingers of a few 10s of people and (total,
industry-wide) corporate donations to code-generating individuals and
NPOs with no more than 7 significant digits per year.  When they do
spend on public projects, it is most often for very narrow tactical
purposes -- not to make the ecology of projects healthier overall.  In
significant proportions, they spend R&D money on entirely in-house
projects that, while rooted in free software, benefit nobody but the
companies themselves.

You know, it's easy to make a few quarters for your business unit when
you, in essence, cheat.

So the crisis is that in the medium term, as engineering businesses
go, these aren't sustainable models.  And when they start leading
volunteers and soaking up volunteer work for their own aims, and
capturing mind-share in the press, one has to start to wonder whether
they aren't, overall, doing more harm than good.  And then there's
some social justice and labor issues....

Bill Gates, when he says that free software is a threat to innovation,
is currently correct.  UnAmerican?  You bet!

And, btw, surprise!: In the free software world, corporate GCC hackers
are the relative fat cats.  Go figure.


-t

Itching and scratching (Re: source mgt. requirements solicitation)

[Stan Shebs]

Tom Lord wrote:

>
>And, btw, surprise!: In the free software world, corporate GCC hackers
>are the relative fat cats.  Go figure.
>
That's because GCC hackers are doing things that are worth serious
amounts of money to people that have it to spend.  Apple has signed
up with GCC because it solves more of Apple's problems more cheaply
than the several proprietary possibilities, and having made it part
of Mac OS X, Apple's overall corporate health is now partly dependent
on GCC continuing to be a good compiler, and on fixing remaining
problems, such as slowness.

If you were able to convince Apple mgmt that you could make GCC
10x faster not using precompiled headers, I think you could name
your price and get hired the same day; that's how important the
problem is to Apple.  (You're going to have to be really convincing
though; our mgmt has listened to a hundred pitches already.)

Speaking more generally, the folks that get paid to do free software
are the ones who are solving the problems of people with the money.
It's up to us to be clever enough to figure out to solve the specific
problems in a way that improves architecture and infrastructure.
That was a key but underappreciated aspect of Cygnus' development
contracts; we would always try to go after projects that included
infrastructure improvement, but if necessary we would do something
that was random but lucrative and use the profits to pay for
generic work.

To put it more simply, find a rich person with an itch, and offer
to scratch it for them. :-)

Stan

Re: Itching and scratching (Re: source mgt. requirements solicitation)

[Tom Lord]

       > And, btw, surprise!: In the free software world, corporate
       > GCC hackers are the relative fat cats.  Go figure.

       That's because GCC hackers are doing things that are worth
       serious amounts of money to people that have it to spend.

I didn't mean that it is wrong for you to be well paid.  I meant that
you have a lot of clout.

	Speaking more generally, the folks that get paid to do free
	software are the ones who are solving the problems of people
	with the money.  It's up to us to be clever enough to figure
	out to solve the specific problems in a way that improves
	architecture and infrastructure.  That was a key but
	underappreciated aspect of Cygnus' development contracts; we
	would always try to go after projects that included
	infrastructure improvement, but if necessary we would do
	something that was random but lucrative and use the profits to
	pay for generic work.

Was it customers who underappreciated that?  or was that a selling
point?

	To put it more simply, find a rich person with an itch, and
	offer to scratch it for them. :-)

Ah, well, "The Cabots speak only to Lodges and the Lodges speak only
to God."

-t

Re: Itching and scratching (Re: source mgt. requirements solicitation)

[Stan Shebs]

Tom Lord wrote:

>
>	Speaking more generally, the folks that get paid to do free
>	software are the ones who are solving the problems of people
>	with the money.  It's up to us to be clever enough to figure
>	out to solve the specific problems in a way that improves
>	architecture and infrastructure.  That was a key but
>	underappreciated aspect of Cygnus' development contracts; we
>	would always try to go after projects that included
>	infrastructure improvement, but if necessary we would do
>	something that was random but lucrative and use the profits to
>	pay for generic work.
>
>Was it customers who underappreciated that?  or was that a selling
>point?
>
Sometimes it was a selling point, sometimes the concept was too subtle
for the customer to grasp.  In the mid-90s, a good percentage of time
still had to be spent explaining free software, reassuring people that
GCC didn't cause its output to be GPLed, etc.  It was interesting to see
how much variation there was among customers, and also how important it
was to have actual sales people in the process - engineers left to
themselves would rathole on side issues and never get around to the
actual dealmaking.

Stan