bob at redivi.com
Sun May 23 22:17:51 EDT 2004
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
> 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
> 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)
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 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
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,
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).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2357 bytes
Desc: not available
Url : http://lists.nycbug.org/pipermail/talk/attachments/20040523/5c9d6851/attachment.bin
More information about the talk