I posted this to the Lua mailing list when I saw a discussion about getting a project plan out of the Lua team. You can read the discussion when the messages are posted. Look for “Degenerative” for the main part of the talk. My reply though, is most important (of course).

Lua Is Not A Product (Re: Degenerative discussions)

On Fri, 28 Dec 2007 20:19:21 -0800 Tim Kelly 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 its 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.