[nycbug-talk] eurobsdcon

[Bob Ippolito]

On May 23, 2004, at 9:13 PM, Hans Zaunere wrote:

>> -----Original Message-----
>> [mailto:talk-bounces at lists.nycbug.org] On Behalf Of Dru
>> Sent: Sunday, May 23, 2004 8:00 PM
>>
>> I've been invited to give a non-technical talk aimed at users
>> at this year's EuroBSDCon (www.eurobsdcon2004.de). I'll
>> probably end up being the only talk which isn't delivered by
>> a developer aimed at (primarily) developers.
>>
>> I'm thinking of something along the lines of "but I'm not a
>> programmer, how can I contribute to open source?" Does anyone
>> have any suggestions on what they'd like to see in such a
>> presentation? So far I've come up with:
-- cut --
>> What other ideas have you guys seen, done, or heard of? Which
>> URLs are worth mentioning? Or is this talk even worth doing?
>
> I think it'd certainly be worth doing.  Depending on how non-technical
> you want to get, there's often an overlooked aspect of open source.
>
> Just like any project (whether it be software or not) there are
> mangerial and organizational issues that are often overlooked.
> Programmers are good at programming, but typically not organizing.
>
> I think there could be much more open source success (especially for 
> the
> smaller projects) if non-technicals could feel welcome and knowing how
> they can participate.  This is why I think this talk has a lot of 
> value.
> Think project management, marketing (a term I use loosely), financial
> considerations, legal considerations, etc.  This brings in people with
> little or no skill technically, but that offer skills most tech-savvies
> don't have.  The merge of these skills, however, truely makes success.

[somewhat offtopic.. but]

One of the biggest problems is communication.  Users (technical or 
otherwise) of software products don't generally speak up.  This does 
nothing whatsoever for the software, especially free (as in beer) 
software.

I'll give a little example of how not to be a good user (from 
experience, it was me):

A few weeks ago, I needed to process a bunch of Excel files in batch.  
I did some research on the topic, and I found that there are 
essentially two solutions out there that met my requirements and 
claimed to do what I wanted:
- xlHtml
- Spreadsheet::ParseExcel

xlHtml was nice and fast, but it just didn't produce correct output for 
the small set of input Excel documents I had.  Not good!  I took a 
quick glance at the source code, didn't see anything obvious, so I 
dropped it.  This was for a paid project and I wanted to get it done 
quickly so I didn't try very hard to make it work and I didn't contact 
the developers.

Spreadsheet::ParseExcel was MUCH slower and is some godawful perl code, 
but at least it seemed to give correct output for the spreadsheets that 
I needed to process.  I haven't done major perl development in a few 
years so I wasn't even going to try and profile it to find the 
bottleneck(s), I just decided to live with the performance 
implications.  Again, I wanted to get it over with quickly, so I didn't 
give any feedback whatsoever to the developers.

Are either of these products going to get any better because I tried 
them out?  No.  I didn't contribute feedback, file bugs, submit feature 
requests, money, patches, documentation, examples, support, advocacy, 
etc.

Software, especially open source software, is an evolutionary process 
guided by the constraints of its contributors (contributors being a 
very general term).  If you don't contribute anything AT ALL to it, 
it's probably not going to evolve to satisfy your needs.  If you want 
software to work for you, the major contributors in that software's 
community have to know what you want.  There are plenty of ways to make 
that happen: file bugs, post to mailing lists, hop on IRC, post to 
forums, write articles, donate, buy stuff, ask for help, etc.  Most of 
it's really pretty easy, but makes a difference when there's a lot of 
people doing it.

As a software developer, I've definitely added features or fixed bugs 
in software that I didn't need myself because someone asked.  If they 
didn't ask, it wouldn't have have gotten done.  Of course, sometimes 
you won't be heard, so you should speak louder (substantial monetary 
contributions work as a great amplifier), live with it, or cut your 
losses and take your business elsewhere.

In the smaller projects I've been involved with, what we really need is 
FEEDBACK, people to help others who don't need direct support from the 
developers (answering FAQs politely is boring, especially when you've 
frequently answered them), and people who are willing to spend the time 
to write articles, documentation, tutorials, etc. (writing 
documentation is generally not a top priority for those who know the 
code very well and would rather fix bugs and add features).

-bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: not available
Url : http://lists.nycbug.org/pipermail/talk/attachments/20040523/5c9d6851/attachment.bin