Date: Wed, 19 Feb 2003 19:37:10 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Paul Robinson <paul@iconoplex.co.uk> Cc: chat@freebsd.org Subject: Re: Open source (was RE: Hi!Dear FreeBSD!) Message-ID: <3E544D66.4065A126@mindspring.com> References: <IPEDKJGCDFHOPEFKLIDHOEJLCCAA.paul@iconoplex.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Paul Robinson wrote:
> Terry Lambert wrote:
> > You would be hard-put to simply design a new set of systems, and
> > simply "throw the switch", and have the new organization spring,
> > full grown, from Zeus's head,
>
> Actually, the ease with which you can do that is inversely proportional to
> the complexity of the system. I'm sure that between us, everybody on the
> freebsd lists could get a working "count_to(x)" function working perfectly
> within the next 3 months and we would be confident in it's "correctness"
> without having to test it too much. I don't think the same could be said if
> we decided we were going to write a functionally equivalent piece of
> software to say, Visual Studio .NET in the same time frame and then just
> "release it" on a given day. That's why the concept of -RELEASE always makes
> me chuckle a little.
This was actually a comment on the systems of operation of the
project itself, not the software that a project produces.
I think, sometimes, that software people reuse terminology so
quickly that they become "vocabulary blind". For example, if
I were to say that this discourages "introspection", you could
think I meant something other than philosophical self-examination.
8-).
In this context, "systems" was intended to mean things like "the
process by which you get increasingly sanctioned on a mailing list
for trolling, until you are removed from the list", or "the process
by shich SPAM source addresses are reported to a blackhole list,
and less immediately, but more permanently banned from participation
in the mailing list". It also means "the process by which one
becomes a committer", "the process by which one becomes a core team
member", "the process by which one has one's commit bit revoked", etc..
> > OpenOffice is a different phenomenon entirely. It is a copy of a
> > commercial product, with very little in terms of innovation. For
>
> Ah, but it opens a lot of doors. Five years ago, no even two years ago, if
> you'd said to the boss of a small non-tech outfit "install Linux or FreeBSD
> instead of Windows", the biggest thing preventing him/her from doing so
> would be the fact that they wouldn't be able to send and receive Word and
> Excel spreadsheets. StarOffice got rid of that barrier, then created another
> one that OpenOffice took down again.
I think the biggest barrier was "It's not Windows, and I pay for
Windows anyway, when I buy the machine". I think that's still the
barrier, in fact. Draconian and repetitive licensing, so now it's
nearly impossible to own the software outright, is a factor in
favor of non-Windows solutions. On the other hand, can you really
ever own GPL'ed software outright, either? Well, no, but you can
limit the number of times you pay for it.
If the licensing model that Microsoft want ("software leasing") ends
up becoming the standard, then it's not going to be possible to, for
example, buy a computer with software installed, and then amortize
your total costs over the (currently allowed) three years. The costs
go up. When cost accounting is forced to change, then you will see
attitudes change... that is, if the software is there... there's not
a "QuickBooks" for non-Windows systems, let along a MAS-90.
> > What kind of idiot would create a word processor that required
> > documentation, without some overriding business/systems need for
> > a need for someone to provide it? What is so incredibly hard
> > about merely the *idea* of word processing, such that this
> > should be necessary?
>
> It's a change of contextual thinking as far as the user is concerned. That's
> why stories of secretaries putting Tippex all over their screen exist. Word
> processors are yesterday's news these days, but back then, the idea of a
> Word processor or a spreadsheet and how it operated were alien concepts.
"Cut-and-paste" was a well known phenomenon before the computer;
that's why we call that operation on a computer "cut-and-paste"
today. Most software operates by analogy, not allegory: people
generally have no problems translating: it's what people do; it's
what human beings are good at, above all else.
> Even now I know of accountants who have been working in small villages with
> paper based systems that don't understand that a spreadsheet *automatically
> does the maths*. When I have explained it, they've sat there in awe at how
> easy fiscal modelling becomes, never mind book-keeping. That's the point
> they become excited. Once that mental jump is made, it's easy. Making the
> jump though...
I think the parables of "Whiteout" ("Tippex") on the computer
screen, and the accountant who doesn't understand simplistic
spreadsheet operations are just that, parables: "Be like Gallant,
not like Goofus". They are designed to teach.
What I *have* seen be hard to grasp is the concept of "iteration",
and, most particularly, the concept of "conditional termination".
It's not that these are really hard concepts to put across, it's
that the tools think about these issues like programmers. For
example, if I have an IRR (Internal Rate of Return) function,
which I want to apply on a monthly basis, I want it to stop applying
it to new cells to the right of the spreadsheet when the balance
in the previous cell goes to zero -- no mor payments needed. To
specify this in spreadsheet terms requires a complex formula, which
include both a value comparison and a value substitution, with a
special case value comparison for the first value that causes the
principal to go negative. There is no such thing as "until balance
is zero", and there is no automatic concept of "payment balances are
definitionally prohibited from becoming negative".
When you ask someone to enter a "formula" which is actually a complex
loop with two branching conditionals, you are asking too much of the
end user: you are asking them to think like programmers, not like
accountants.
> > In other words, they are able to successfully defend their
> > existing market by way of increased complexity, and the inability of
> > Open Source equivalents to manage complexity. We see this in the use
> > of "embrace and extend" tactics, and in the pushing of increasingly
> > (and technically unjustifiably) complex standards through the public
> > standards processes.
>
> XML being one of those, IMHO.
Yes. The lack of standards requirements for the contents of XML
documents -- the lack of explicit limits on extension -- make XML
file formats an easy thing to manipulate this way.
> MS has been good at this for a while. They're cleverer than perhaps
> they give themselves credit for.
I doubt it. Intent is the easier explanation, for elegant systems.
> If it wasn't for that damned calendaring thing they came up with,
> Exchange wouldn't be in too many SMEs these days. This isn't about
> complexity though, it's about functionality. It goes back to the MS
> Program Managers understanding what a user would like, and getting
> it into the product. Nobody does that in the Open source world
> outside of their own organisation. Even when the need is clearly
> identified - "we want shared calendars like in Outlook" - the
> complexity of producing an identical product THEN becomes overwhelming, so
> they produce something inferior based around a webmail package. This is a
> flaw in the process, it's virtually impossible to fix.
I really disagree with this. People wanted calendaring, and they
wanted certain features associated with calendaring. Building it
into OutLook was actually a negative thing for most people, given
the lack of automatic triggers and other features that can't come
from a protocol requiring active participation. By building it
into OutLook, they introduced a number of synchornization and a
number of logistical problems, which could not be easily overcome.
If you look at a program that does *only* calendaring, like ON
Technologies' "Meeting Maker", in comparison, these deficiencies
become really obvious; for example, you have to explicitly check
for new mail for your schedule to be updated, and even if you do
this at defined intervals, the operation is not something that
occurs within a reasonable human factors timeout. Likewise, a
resource such as a meeting location, which does not have an email
address of it's own, is a second class participant: you can't
"invite conference room 2", except by proxy, so resource conflict
resolution becomes very difficult. Netscape calendar screwed the
pooch in almost exactly the same way, by leaving out notification
triggers -- a consequence of being based on LDAP, rather than
something like LTAP.
The inferior webmail packages are more a sympton of "web services
fever", where people believe that they can replace real applications
with things that live on a web server somewhere. It's why the web
services industry never really took off. Microsoft using email for
the same thing has the same problems; even if you proxy via an
Exchange server, your back-propagation feedback delay is too large
for interactive use.
> Don't get me started on ESR. That's a whole new discussion. Cathedral and
> Bazaar did more damage to OSS than pretty much anything else I can think of
> right now. Good intentions, but the model is terrible. As for sourceforge,
> it's not a failure, it's just not very efficient. That is to say, there is a
> better model for what they want to acheive, the difference is, they've
> actually done it and nobody else has.
The main problem with Source Forge comes down to not forcing the
code to exist and (mostly) work first.
The secondary problem with Source Forge is not one of model, it's
one of cookie-cutter mentality on community. This gets back to
margin: the feedback loops can never be tightened up enough to cost
control the process to below the available margin for participation.
A third problem is the amount of visible failures that result from
the first two, but that's a secondary effect, even if it feeds the
general perception: if you want a project to fail, take it to Source
Forge.
I don't think this can be cast in terms of efficiency: it's a gateing
issue, more than anything, combined with suppression of the most
obvious negative feedback into the overall system. Short of "not
permitting failing projects", there's very little that they could do
to suppress discussions like this one, in which they are cast as
negative examples.
> > Yet Mozilla *did* screw itself,
> > and BSD-based Open Source projects all waited for the trigger of 386BSD
> > and the working code it provided.
>
> Somebody (let's not get into the argument) somewhere, one day sat down and
> wrote the beginnings of what eventually became Unix. They did not have
> existing code, just ideas.
They were researchers, and they were being paid to pursue something;
they "found" UNIX along that path. That's very different than
sitting down and incrementally moving some large stones around, only
to have St. Paul's Cathedral appear 200 years later.
There is a difference between enabling infrastructure and things
built on top of it. Do roads exist because of monuments, or do
monuments exist because of roads?
> If you're saying all software must be evolutionary, then I
> disagree. It's easier for software to evolve over multiple
> iterations and restarts to get to the ideal system than it is to
> sit around and design perfection and then go for implementing the
> "perfect" system but that does not mean all software must be
> evolutionary.
I have a great deal of personal disdain for the idea that there
is always a path from one equilibrium point to another. Or in
other words, I don't believe in evolving software, and I don't
believe in "bit rot". Sometimes, "you can't get there from here".
This is like the idea that you can start out with a hole in the
ground, go from there to a mud hut, from there to a thatched
cottage, then to wood hoses, then to brick, then to brownstones,
and from there... St. Paul's Cathedral. It doesn't happen that
way, it *can't* happen that way. Great edifices do not occur as
a result of evolution.
> > The problem is the nature of the people involved in volunteer projects.
>
> Here we go...
>
> > Instead, your pool of volunteers is made up of people who like to
> > tinker, and are not satisfied with the way things are, but those
> > people generally have no great leadership skills or vision of a
> > future that they are then prepared to work hard at making real.
>
> That's a little harsh. It's true that many developers would rather implement
> things their own way rather than buy in existing products or use existing
> code that isn't quite perfect. Particularly if they know it's easy, but
> slightly fun and can go on the CV.
Forget code, people reinvent "quicksort" and other simple algorithms,
because they can't be bothered to learn history before they start
tinkering. It's not a matter of "not reusing code", they don't even
"reuse ideas".
> > In a lot of ways, Jeff Raskin is right, and still no one is listening.
> > In two of your examples of products that you think should/will be
> > written, you yourself fell into this trap of cloning from bad gene
> > stock.
>
> Agreed. But that's because they work. They work very, very well. If there
> was a better way of doing what they do, I wish I could think of what it was.
> I'd probably not OSS it though, because I'd want to make some cash. :-)
8-).
The answer lies, I think, at the point you have to interrupt your
work-flow, and move one of your hands over to the mouse, in order
to get something done.
> > At a former employer, there was an engineer who believed in this
> > philosophy so completely, they wanted everyone to accept Steve
> > McConnell as their personal saviour. An excellent engineer, but
> > they could not understand my reluctance to join their religion,
> > because they saw everything in terms of process: for them, the
> > process *was* the product, and any business was just a side effect.
> > It was very much like being back at USL.
>
> The process is important, but then my degree is Software Engineering, and
> I'm currently a manager who has little to do with code production. My view
> is probably skewed. The important thing is that the process is supposed to
> be lightweight and non-intrusive. The requirements cpature process is
> important though, and if you can adopt Extreme programming, or at least
> aspects of it, then you can through process increase the quality of your
> product.
The funny thing about the management perspective is that what you
are really interested in is not producing a great product. It's
more about resource levelling and controlling risk. As long as
you can meet schedule, then your rewards are assured.
From a games theoretic standpoint, most management systems are set
up incorrectly to encourage the emergent behaviours that companies
claim they want.
For example, in IBM, your pay is comprised of two parts: your
immediate pay, and your variable pay (what used to be called
"bonus"). This value is controlled by a scaling factor that is
under the control of your immediate manager; after that, the rest
of it is out of your hands. The scaling factor is a function of
a number that comes out of your performance review.
In the old days, all managers and employees had the same dependency
relationship between hierarchical performance and the amount of
variable pay that would be available. This hierarchical performance
was: group, division, company, and for the sake of argument, let's
say it was [60%,30%,10%].
Then someone who did not understand games theory (or beleived everyone
who knew math was in management... 8-)) decided that there needed to
be more cooperation between divisions, and that this was a "grass roots"
issue, rather than a hierarchical "shit rolls down hill" issue. So
they changes the relative weighting between management and line employees,
such that employees were less dependent on group and division performance,
and more dependent on overall company performance. The managers, they
left the same.
The problem is that the main factor under the control of a line employee
is their manager's perception of them. Therefore, the behaviour that
they wanted to encourage was not encouraged, as a simple matter of math.
What they should have done instead is the opposite: make the management
variable pay less depenent on division performance, and more dependent
on group and overall company performance. This would have incented the
behaviour they said they want, since the line employees had much less
control over the overall profitability of the company, and instead
controlled only their ability to please their immediate supervisor(s).
The reason for this little digression is that it demonstrates that
people do that which rewards them, not that which they are told is
important.
> > "Why, if product developement is
> > changed to a fully user and quality-centric model, would people
> > continue to buy new versions of these products?".
>
> User requirements change in the same way as everything else. People don't
> buy new clothes, furniture and consumer electronics on a regular basis
> because they don't have something that was not user and quality-centric when
> it was designed. It's just that the requirements change. With clothing, this
> happens on a seasonal basis for some people. My old TV was fine, so why did
> I buy a 32" widescreen? My VCR was fine, so why a DVD? Functional upgrades?
> Change in perception of quality? Fashion? All these and more play into it.
> Software is no different.
A better question to ask is not "Why replace A with B?", but "Why
replace A with new A?".
There are very few reasons, unless you are a habitual consumer, to
replace your old VCR with a new VCR before the old VCR breaks. You
may claim that you have replaced your VCR with a DVD, but did you?
Did you get rid of all your old media, or convert it to the new
format, or did you buy a DVD *as well* as a VCR?
Frankly, and I've said this before, I would be tempted to get rid of
my VCR, *if* the companies wanting me to switch over to pure DVD use
were to make the value proposition worthwhile: give me credit for my
VHS investment, in converting it to a DVD investment, instead.
How many people do you know who had large VHS collections before DVD,
now have large DVD collections, and no VHS? If there are any people
you know who meet this description, they are people with well above
average disposable incomes. Personally, I know a lot of people with
above average disposable incomes, and not one of them has converted
their entire VHS collection.
> > The value proposition for the mainstream is whether or not they can
> > hire a temp for a week in accounting, and that person will be able
> > to use the tools in place, without needing training.
>
> The transition between WordPerfect and Word happened. The transition away
> from Word can happen. The issue though is whether people can get done what
> they need to, and if there are other advantages. At the moment, advocates
> are harming OSS by telling everybody that OSS has a lower TCO which is bull,
> but not pointing out the real advantages. Unfortunately, those advantages
> can be swallowed up by MS or anybody else on the commercial side the moment
> they wake up and smell the coffee.
I was there for the transition from WordPerfect to Word. It happened
because WordPerfect dropped free support, and the amount of support
required by Word was less than the amount of support required by
WordPerfect, and the cost of support -- including the amortized per
seat cost -- was overall higher for WordPerfect than for Word. And it
happened because Microsoft started "giving away" Word with new computer
purchases, so you were paying the up front cost for Word with each new
computer.
And why did Word Perfect drop free support? Because they wanted to
sell the company to another company, whose valuation on acquisitions
was a simple formula based on profit-per-employee, with no lag factor
to account for quarter-to-quarter hiring and firing.
The whole "OSS TCO" argument is BS, that's true. But so is the
argument that Microsoft has to look over its shoulder and worry
about someone displacing a bundled product.
> > Most people end up conforming their views to the community, rather
> > than selecting a community on that basis, in my experience. 8-).
>
> You evidently didn't spend much time as a teenager then. :-)
Teenagers are brillinat examples of group conformance: "I want to
be different, just like everyone else!". 8-). What group you join
is dictated primarily by who tolerates your presence best.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E544D66.4065A126>