Lua Is Not A Product (Re: Degenerative discussions)

["Zed A. Shaw" <zedshaw@...>]

On Fri, 28 Dec 2007 20:19:21 -0800
Tim Kelly <gtkelly@dialectronics.com> wrote:

> This is out of touch with bidding processes.  Most, if not all, independent contractors have toolkits that make their lives easier.  Those toolkits are based on underlying products.  It would be absurd for anyone soliciting an RFP/RFB to consider a developer that has toolkit based on a product that hasn't been updated in five years.  That does make you dependent on Lua's future if you choose Lua today.

Hi Tim,

I normally don't contribute on the Lua list, just a lurker who uses it
in commercial and non-commercial projects.  I read your comments here
and thought I'd toss out some wisdom.

I'm an open source developer who operates in the Ruby world with a
foot in Java, Python, and lately the Factor community.  I'm also a
professional sofware developer and have worked as a contractor for
large and small companies in many different industries, and currently
work for a bank using open source projects.

What I'd like to do is give you a little bit of advice that might
help you understand two important things about open source:

1) Why what you're asking for (and kind of demanding) is going to
irritate most creative projects.
2) How you can get what you want cheaper and more accurately
as long as you do some of the work.

> (What's wrong with setting a schedule where once a year a new release version comes out with up-to-date bug fixes and non-dramatic features appear?  As long as Lua keeps meeting this deadline, for even minor, minor adjustments, there's no question about the future.  As has been pointed out, the MBAs aren't going to know the differences behind the code.)

I've got a long essay on a very simple concept that I'm going to
compress for you so you can understand the dynamic at work here.
Imagine I break software development clients into two camps:
Collaborators and Customers.  Now imagine I then break projects into
two categories of Implementation and Invention.

Collaborators will participate daily and know what's going on because
they are there and will usually pay variable price because of a higher
tolerance of risk. Customers just want something packaged, want it now,
and will only pay a fixed price and if it isn't perfect they'll bitch.

Implementations are things you've done a billion times or that you can
manufacture with a consistent process and have low risk and low
variability. Inventions are done different every time, require creative
thinking, adaptation to randomness and chaos, and generally are riskier
and variable.

In an ideal world, you pair Collaborators with Inventions, and
Customers with Implementations.  The other combinations end in
disasters and you really only find them in the corporate world where
the force of tons of cash can make those bad mixes work anyway.  In the
open source world where Darwin rules, the good projects gravitate
toward Collaborators+Inventions or Customers+Implementations, with the
former more common than the latter.

The reason some people might get upset at you is that you are saying
(or what they hear) is, "I'm a Customer dammit and I want my
Implementation planned with no risk now."  That's ungrateful and
irritating and insults their hard work.  

Yet, the Lua community and developers say, "We are Collaborators
working on a grand Invention and will do what we want for the art."
That's also insulting as it says you have to be a programmer illuminati
to participate at all.  

This is just the way it is, and the best projects have learned to
balance the two and still have fun and be creative in their own ways.

Now, this hopefully answers the first question:  You can't get
what you want this way because Lua is not a product to be implemented.
Lua is an invention that is constantly adapting and changing, and yes
at the whims of it's collaborators.  And, generally you can't have it
both ways.  To much implementation style (read: planning) in an
invention style project and you lose the collaborators.  I know, I've
left better projects for that many times.

And, this should hopefuly give you insight into the answer to the
second question.

If you want to know exactly what's going on, then you have to become a
collaborator in the invention, not a demanding customer of an
implementation.  When you do this--by contributing code, bug fixes,
documentation, extra projects, and chatting with the people--you get a
real time full feed of exactly what's going on and can have a chance to
influence decisions.

The tools are all there as well.  You can track the source, the blogs,
the projects on Lua Forge, the mailing lists, the IRC channels.  Hell,
a smart man like yourself could probably craft a wicked "Lua Tracking
Console" to do just this and be 100% tapped into the community you need.

Then, when you then go to bid, being able to say, "I'm a major
contributor to the Lua project and creator of 16 Lua based
projects with a direct line to the Lua community."  does much better
than if you had a time line full of lies from Roberto.

Hope that helps.

-- 
Zed A. Shaw
- Hate: http://savingtheinternetwithhate.com/
- Good: http://www.zedshaw.com/
- Evil: http://yearofevil.com/