Testing reports

Colin Law clanlaw at googlemail.com
Mon Apr 16 11:41:56 EDT 2012


On 16 April 2012 16:17, John Layman <john.layman at laymanandlayman.com> wrote:
> 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.

I think you are wrong there.  Most developers I believe work on the
software principally because they use it themselves (or perhaps their
clients use it) and want the bits that they use to work well for them.
 For them the "User Base" that most matters is themselves.  No doubt
they draw satisfaction from their work being useful to others but that
is not the prime reason for the commitment.

>  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.

I don't know for sure but I suspect that the big difference with
Adempiere is that a good number of developers make a living out of
supporting the software.  Gnucash is a much smaller project with only
a very small number of developers.  They have not got the time to add
features or fix bugs that are not relevant to themselves.

Colin L.



More information about the gnucash-user mailing list