Re: sdcc/PIC howto, first draft is up

Byron A Jeff wrote:
> Now on to theme. Frankly it's poor presentation to outline what is clearly
> a good idea with a negative tone. I would almost suggest dropping everything
> up to section 1.4 Or if you feel really strongly about it present it in a
> positive light.

Hi Byron,

I note your concerns about a negative tone in the document.

However, I'm feeling at the moment that the ideal pitch might be
somewhere between our respective positions.

Let's face a basic fact - we still face a situation where nearly
everyone uses software whose exact behaviour cannot be discovered,
discussed or modified without one committing criminal offences. In other
words, proprietary software.

The numerous advantages of open source software are well known to most
or all on this list, so I won't preach to the choir.

What I will put forward is one of the major reasons, perhaps the main
reason, why open source software continues to be rejected by a majority
individuals, organisations and corporations:

  Open source software - on the whole - alienates newcomers.

Putting aside some of the wonderful exceptions like OpenOffice.org,
Mozilla, Thunderbird, Firefox etc, much open source software puts across
a vibe that says: "Easy learning curves, ease of deployment and coherert
documentation are luxuries of the lowest priority."

To newer users, this can come across as "I can't be stuffed making my
software comfortable for you to use!". To many newer users, this
translates to "This software is crap!" The unintended vibe of elitism,
even techno-snobbery. is enough to send most packing off to the familiar
comfort of consumer-oriented proprietary software.

Relating all this to sdcc - writing a C compiler toolchain is a
non-trivial task. The authors of sdcc core and chip-specific parts have
done magnificently well. What a gift to the open source community - a
working compiler that can build binaries for such a diversity of targets!

However, much of sdcc's value is lost because there are gaps in the make
setup, the user documentation and (at least for Debian) the binary
packaging. These gaps are tiny from an internal technical point of view,
but to newer users, they swell to major obstacles.

Compare to ccs, cc5x etc which are almost effortless to use, where
newbies can be up and running in minutes without a single head-scratch.

If there are any sdcc devs reading this, I ask you to please prioritise
your efforts with even just a little more consideration of newer users,
and to value the goal of making open source software whose overall
usability makes it competitive with proprietary offerings. Your manual
is mostly fine, your make setup is mostly fine, as is the installation
structure, but these have enough holes to make many think "sdcc isn't
ready for PICs".

What I do when writing/publishing code is to do an 'installation and
orientation walkthrough'. I pretend I'm a new user. I often download my
tarballs from my distro websites, and I walk in the new user's shoes as
I crack the tarball, hunt for README, INSTALL, doc/index.html etc files.
I then follow my own doco, and proceed to install and start using the
software. At every step I ask myself "Am I at risk of jumping ahead of
the reasonable grasp of the average user?"

Many other developers follow this approach. Unfortunately there are
still too few of us.

Failure to package/document software with a user-centric focus, using an
approach like the above, sadly contributes to making Microsoft et al
becoming even more powerful.

-- 
Cheers
David