On Wed, 15 Aug 2001, Stas Bekman <[EMAIL PROTECTED]> wrote,
> On Tue, 14 Aug 2001, Hasanuddin Tamir wrote:
>
> > On Tue, 14 Aug 2001, Stas Bekman <[EMAIL PROTECTED]> wrote,
> >
> > > On Tue, 14 Aug 2001, Hasanuddin Tamir wrote:
> > >
<snip>
> See my other post in this thread. There are places, but if you know about
> them, how do you make others know about them? Run a simple test and ask a
> few of your Perl programmers about this? Do they know?
About those places? It would be awkward if they didn't :-) I'm the source
of the information.
> > > > We have internal tool for web application development. There's some
> > > > effort to redesign it and formulate the way we release it to the open
> > > > source community. But I don't decide things, I only recommend them.
> > >
> > > that's something completely different. You are talking about convincing
> > > your company to release the code to the open source community. (I
> > > suggest that you start a new thread, or otherwise it'll be lost in the
> > > flood of the current thread :)
> >
> > I brought it on just as an example to see how your idea will fit on
> > the situation like mine.
>
> but your situation is different. You already know that you want to release
> your code and now you *only* have to find how :) I'm talking about talking
> to those who *don't* know yet. Think of it as being a missioner.
It's still not so clear about the way. But when it's clear and we finally
make it, I plan to make it as case study. As a tool by itself, it's aimed
for other developers. As a tool that produces "final things", these final
things are aimed for the corporates.
And yes, my situation is different from what you described. They are my
"target" too. Say, after talking to them, they use/expand the tool, or
they adapt our processes. It doesn't really matter in either way.
> > > I'm talking about educating companies about CPAN and such, for their
> > > internal product which they probably would never release.
> > >
> > > Basically all is needed is to make these companies aware of the forums
> > > where their Perl programmers can ask questions, and thus improve their
> > > productivity. e.g. Q: "I'm writing a wrapper around cvs, may be you know
> > > somebody who wrote such a wrapper already", A: "Sure, here is the link on
> > > cpan.org, in the future you can use search.cpan.org to find the available
> > > modules by yourself."
> >
> > In this case, I don't know to whom we should talk to in that company.
> > The manager? The programmer? Well, both I guess.
>
> The more the merrier.
Got it.
> > I still don't know if my company can do it to other company, but
> > personally I can.
>
> And you should, if you care. I know you do.
I have, and still will. It's considerably sad to see the situation about
Perl here. It *is* popular (among techies), both in good and notorious
ways in various opinions :-)
Those who've touched Linux, have fired up the perl she-bang as well.
They either end up hating Perl or loving it, or, they go back and forth.
[WARNING: This is a weak claim. It's only by a general view on some
technical discussion forums, including our local Perl Mongers (bandung.pm)]
So, when a friend in PM offered me a position as an editor for Perl
section for a new 'web and internet mag' (the first edition is due this
September), I took it. Even thought I don't have any experience in
technical writing, publicly. Writing a perl script is usual. But writing
about the script itself and explaining how to write one is a completely
different thing. But he convinced me. And the journey has begun.
BTW, is this also a right place to discuss writing strategy/technique?
san
--
Trabas - http://www.trabas.com
