Subject:
Re: [gnupic] sdcc/PIC howto, first draft is up
From:
Byron A Jeff ####@####.####
Date:
17 Jul 2005 13:35:17 +0100
Message-Id: <20050717123514.GA19969@cleon.cc.gatech.edu>
On Sun, Jul 17, 2005 at 08:22:56PM +1200, David McNab wrote:
Just an E-mail aside. The linuxhacker.org list tends to drop the original
author on the CC list for replies. So you end up getting two copies. It's
somewhat annoying to me. So I and pretty rigid about editing the headers
before sending out a post. I figure they may become an extended discussion.
So it's something I just wanted everyone to be mindful of.
> 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.
Like I said, it doesn't have to be Mary Poppins.
> 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.
In fact the software is packaged such that it's very difficult to do any of
those activities. Though the US Digital Millinium Copyright Act specifically
allows for reverse engineering for compatibility purposes. It's unclear
what's going to happen when Digital Rights Management hits the market in
full force though. Software and Media providers want to have complete
control over their content. They really only want to sell users a "right to
use" under their terms. I see where you are coming from.
> 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.
But you may want to spend a section preaching it in your document.
> 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.
Agreed.
> 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."
I understand the reason for that. It generally comes down to "Those who can
do, won't bother to document." The developers basic stance is that they
have given the raw material for you to be successful. It's up to you to
figure out how to assemble it.
There is in fact some satisfaction in doing it yourself. However, most folks
don't have the time or the inclination to do that. They have a task to do,
and they just want to get it done. And they will pay for the convenience
of easy learning curves, ease of deployment, and coherent documentation.
And as you outline below, I think that hardcore development and packaging
are somewhat different activities. Projects need a different group to
handle those aspects. Big thinkers, as a class of developers, generally
aren't interested in mundane details.
>
> 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.
And that's why it's a multi billion dollar industry.
> 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!
Now that's the kind of statement you should open with! Start with bright
eyed enthusiasm. That's the state a newcomer will enter into this document.
So encourage it.
> 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.
Include this statement too. I call it "pitfalls are sinkholes." Exactly as
you stated, even the most minor deviation is major trouble when you are a
newbie.
>
> 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.
This also exposes the difference of Open Source, which often is a passionate
self serving development model, and commercial proprietary, where
everyone involved is trying to make a living. The compilers you mention are
effortless because if they were not, they would not attract new customers.
No new customers means no sales, which means no profit.
But open source developers develop because they want to, not because they
have to. And as highly technical and accomplished developers, they generally
don't see the issues with minor bumps in the road. They experience them
every day.
I'm not saying that it's right. I'm just saying that's how I see it.
The solution is to have someone just like you come along and start filling
the gaps. In short, have other groups of the community handle the packaging,
marketing, documentation, and ease of use stuff. You are doing that for sdcc.
For that I am grateful.
> 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".
But that's the beauty of Open Source. They don't have to do it. Someone like
you and I can come behind them, patch those holes, and rerelease the results.
It doesn't have to be their responsibility. You don't have to ask permission
to do patch. Just do it!
Why not join the sdcc team? I'm sure it isn't a closed community. You can
then bring your point of view to the table.
> 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 hate doing that. Package management was the final straw of my abandonment
of Slackware Linux. I am slowly moving everything to Debian because apt-get
is one of those ease of use tools that makes life simple.
I probably should be a Gentoo user. However as you have pointed out,
sometimes the aggravation of getting over the initial hump doesn't seem to be
worth the time to do it.
I introduce new users to Linux by giving them a Live CD. No setup, no config,
no install, no nothing except drop the CD in a reboot. It's instant
gratification. However, the limitations including slow runtime, difficulty,
saving, lack of new software install facilites, and the like quickly
become apparent. But by then, new users have seen enough of the hook that
if their interest is peaked, then they will be willing to invest a bit more
in setting up.
Maybe we need to do the same and build a GNUPIC Live CD. Something DSL or
Knoppix based with all the software a new PIC developer would need. Make
it so that it's all configured properly and ready to go.
> 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?"
You're my hero man! That kind of beta testing would drive me to drink.
> Many other developers follow this approach. Unfortunately there are
> still too few of us.
It takes a mindset. And a mindset that is often beyond the initial
developers. Another issue is that setup is important too. What works on
one machine (the developers) may not work in the average case.
> 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.
We can't worry about Microsoft, Apple, or anyone else. I also believe that
many OS developers are not interested in taking over the world either.
I think you see my theme. Let the hardcore developers develop in whatever
model works for them. Then let the "Evil Geniuses (TM)" of the world
figure out how to package that raw material in such a way that it can
really make a dent.
I can tell you, if you press hardcode folk out of their comfort zone, they
will simply stop sharing what they develop. I haven't released my NPCI
interpreter/compiler combo in any meaningful way because I know that it's
going to take quite a bit of packaging and support to make it useful. And
until now I wasn't willing to invest the time and effort to make that happen.
I will keep your thoughts in mind as I start to roll NPCI in the coming
months.
I realized that we've wandered away from the initial point. So let me come
back to it. I agree with you on the situation. However, the negative tone
of the document will turn off newbies (or anyone else for that matter) just
as quickly as the initial frustration you felt when you went through the
process. Don't project that frustration. Instead set up your story as:
"When I started the process of using sdcc, I was frustrated. I worked through
it. This document shows you what I learned."
Project helpfulness, not frustration. You'll get more converts that way.
BAJ
