Testing reports

John Layman john.layman at laymanandlayman.com
Mon Apr 16 11:17:33 EDT 2012


Given the focus on "patches" rather than process (even the terminology is
telling), I can't help but wonder how much experience the development cadre
has outside the lab.  I'm not sure why you personally attach value to your
involvement in this effort, but the end product has value only in proportion
to whether or not it delivers value to its user base -- and that base will
value the software for different reasons than your (apparent) concerns
reflect.  When you see a list of the most successful open source products,
you can't help but be struck by the fact that the majority are targeted at a
technical audience. There is clarity about the mission, clarity as to who
the customer is, and a big intersect between the set of all customers and
the set of potential developers.   GnuCash is a horse of a different color,
and so this constant "show me yer patches" refrain is incredibly silly.
 
Organizing an open source effort exclusively on the principle of developers
"scratching an itch" omits one half of the equation -- that's stakeholder
involvement.  Given this SMYP attitude, you'd think that that Big INTERSECT
exists for GnuCash, but that isn't reality.   The vast majority of
stakeholders for software like GnuCash will never be able to contribute
code, and the proportion of stakeholders to contributors will become
increasingly lopsided.   Feedback from non-contributing customers will just
increase, and you'd be foolish not to anticipate this.  The longer you
manage the project by scratching itches rather than by a functional
stakeholder feedback loop, you'll just be stumbling along and getting more
and more irritated by negative feedback.

Right off the top, I can think of a couple of open source accounting
projects that fractured due to lack of clarity.  A fork of one of these
(Adempiere) is an exemplar of the difference between a process-driven
approach to open  source development and a group of contributors just
wahooing "patches" into a code bucket.  The Adempiere project has recognized
the need for roles, responsibilities, discipline and oversight.  The have
different strata of developers, rotate through oversight roles,  and the
major contributors have responsibility for defect arbitrage and quality
control. It's not just about cranking code. Their defect tracker isn't a
bottomless pit.  They have their finger on the pulse of the user community
and work at addressing the users' pain points, as opposed to whatever
tickles a developer's fancy.
 
It's swell that you have the spare cycles to volunteer effort here.  I do
not, but I wouldn't care to devote precious time to a patch-fest even if I
did.

-----Original Message-----
From: Derek Atkins [mailto:warlord at MIT.EDU] 
Sent: Friday, April 13, 2012 9:29 PM
To: john.layman at laymanandlayman.com
Cc: 'John Ralls'; gnucash at double-bars.net; gnucash-user at gnucash.org
Subject: Re: Testing reports

"John Layman" <john.layman at laymanandlayman.com> writes:

> Regardless of the fact that GnuCash is built on the backs of voluntary
> effort, it serves a customer.   And the Cost of Quality where GnuCash is
> concerned is no different than with a commercial product.  Whether or 
> not GnuCash is purchased for a price, the customer does incur cost in 
> using it, and what are termed (in CoQ lingo) External Failure Costs 
> are largely borne by the customer.  Just as with commercial products, 
> the cost of GnuCash can rise beyond what the customer is willing to pay.

At which point the devs would gladly give you triple your money back.

Seriously, this is a volunteer effort.  People scratch their own itches. If
you don't like it, you don't have to use GnuCash.  Or you can pull up your
breeches and help out because it's YOUR itch and you see a problem that
needs to be solved.

Honestly, that's pretty much how every dev got involved -- they saw a
problem that they thought needed to be fixed.

So, like John Ralls, I eagerly await to see your patches that fix this.

> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available



More information about the gnucash-user mailing list