Yes, the idea has allready been brought up before but i wanted to see how many of you really wanted this, i will state the benifits for all parties below:

Tom:
Pros:
Less work on your end in terms of solving software issues and adding features
Possibility for more efficent code to be implemented, introducing new ideas
Cons:
Bad software intoduced that may cause massive failure (intended or accidental)
More work on organizing how software is submitted and the fact that the code must be looked over before implementation
Incompentent software programers
Not to many people know how to code an ECU, a few people here show some great knowleage but I believe that there is a VERY SMALL # of these people who understand ECU coding
Oh and the fact that this is ur hard work released to the public to possibly copy and re-use

Us (The User):
Pros:
More features, a good future for continous updates to be made
Problems and so on can be solved quickly and can be easily identifyed by the coders
Faster implementation of new features
Better code
Cons:
Malicious code could cause catastrophic failure (ie. blown engine)

Anyone else have anything to add to this just PM and and i'll edit it, please post ur comments, Tom could possibly be the first one to come out with an open-source ECU code (if he so pleases)

 

Well, I can't exactly speak for Tom, but I wouldn't advocate taking a product like this and making it open-source. There's a lot of reasons for this, but one is that the ECU+ is a piece of HARDWARE, and much of the software is in there, in the box. It's not something you can develop using an off-the-shelf package.

Then there's the sunk R&D time Tom invested. Perhaps some day Tom will get paid for all those years of evenings spent working on it. In the mean time, getting to profit from some ECU+ sales makes it at least pay back a little bit. Although open source would not necessarily mean nobody would take it and design a work-alike product to sell, they could.

The final point that comes to mind is that one of the things that has made the ECU+ really popular has been the customer-focused way Tom has developed it, fixed problems, and added features. The product has evolved pretty quickly to its current state, and in my experience any product designed or managed by a group can't move as quickly as one that's under the complete control of one person.

On the other hand, having a good discussion like we have on these forums and over on the ECU+ forums is a sort of open-source process, in that the community is influencing the direction the product will go, and gets to benefit from the feedback the members contribute. So in that sense, you might call it open-source design.

--Dan
Mach V
MachEVO.com

 

Here's my opinion: This isn't linux, no open source.

I would think it would be cool if Tom had some people helping him out, but opening the source to everyone is a bad idea.

 

That would be a horrible idea. Linux by itself is a horrible piece of software, only made acceptable by RedHat. Redhat is a company that sells its services to support the software and provide updates for it. The same would apply to making ECU+ Code open source, support and updates would be horrible and unreliable.

 

Horribly incorrect statement. Redhat is for Linux newbies (like myself), as are a few other brands. Most real linux users are big with Gentoo, or atleast they were when I got out of the IT field.

Either way, saying linux is horrible piece of software makes geeks everywhere cry.

This isn't about Redhat, linux, or operating systems however, so let's just say open source is bad for ECU+

 

I don't see a reason to have open source either, its not like Tom isn't responsive to all of our requests.

 

Open Source for the ECU+ = HELL NO........

 

I dunno.... I'm not sure how open source would work (I would certainly not be helpful... haha Mechanical engineer... not computer) but I have thought on more than one occasion that he is only mortal.... if he dies, this fantastic evolve-able piggyback just becomes an advanced SAFC... Just something to think about.