RomRaider

I think I'm with a bunch of other developers with WRX's/STi's aching to contribute to this, but in this project's current state, this is a difficult task.

Let me explain:
I love what you guys have done so far and I want to help out with the generalized UI. However, I think the code could lend itself to development by a large team a little better.

It probably made sense starting out on this project to reduce the coding infrastructure and reduce overall complexity because of its small-app nature. What I'm reading on NASIOC, hearing from reputable tuners, and my own experience tells me that this thing is going to really take off. This means that the project itself will mature. It will no longer be a simple CRUD application because of new features like RamTune, Auto-tuning, and possibly mutable graphical map representations.

In order to expand the developer base, I believe a few things will be needed.

The very first thing that needs to be finished is this release. The developers have been very flexible about allowing new features during the v5 release cycle, but it seems to have caused the release date to slip and induced a tad bit of code-churn. Plus, from what I've seen in source control, there are a lot of key features that are half-implemented and the other half is in the minds of the current developers (very cool stuff, btw).

Once v5 is GA, the code itself needs to define some strong interfaces that coders at different levels can agree on. This will allow the UI guys to more freely do their own thing and not rely on code being finished in other areas. I have some ideas on how to accomplish this too.

Lastly, RomRaider could assume the popular large-scale open source development scheme. The branches in source control could be organized to reflect functional areas. There are already a handful of core developers that the project manager trusts (this is "qoncept" if I'm not mistaken). Each of these developers can assume a particular area and have developers work underneath them, and those developers would have branches... When a developer checks something in, they can tag it and suggest that it be included in the parent branch. The owner of the parent branch reviews the changes and incorporates them if deemed appropriate. And so all appropriate changes are reviewed and brought back into the original branch. Yes, this scheme represents a significant overhead versus the current one. However, it'll allow the project to harness potentially hundreds of developers.

I want to add that I'm willing to be a part of this project no matter how it is managed (never could say that about a project before, paid or unpaid ). I imagine someone on the development team has something that I can help with. I currently own an '04 STi, so I can't really develop/test any I/O-related stuff, but I'm up for anything else. Just put me in, coach!

Cheers,
J

P.S. Any other software engineers out there that wish to contribute should chime in

I have had numerous offers to help me with what I have signed up for, which is getting the code from ecuflash integrated as a flashing module (without any QT stuff mixed in, gcc (g++) compiled). Unfortunately, I don't have the time to devote to this until ~3-4 weeks from now (sometime in later May I will have hours free after work to work on the code and test as well as on the weekend), but I think this is lower on the totem pole right now anyway. It would be great to have more developers added and some project management strategy including many software developers/engineers/testers contributing. I agree that the user base has expanded tremendously and I have been successful at actively promoting the software (probably helping to add to the growing list of feature requests). I personally think ecuflash and RomRaider should merge and adopt a BSD style license (with the UI being RomRaider based). Open source is great, but as the project grows and gets into competition with other closed source solutions, perhaps some of the starters of the project could reap some financial gains as well. They definitely deserve it. Otherwise I fear companies that make the closed source projects are going to steal the geniuses we do have working on it (by hiring them), especially Bill (merchgod) and Jared (qoncept), and the project would probably die. Right now, (like everyone else doing this including Cobb and ECUtek) we need more disassemblers (all we have now really is Bill). I will be able to dive into that some more after I hone back up on my asm skills and get the flashing module to a maintenance/feature add level of dev, but I cannot devote the time that Bill does to doing disassembly (plus I won't be nearly as good as Bill is, as it has never been one of my things). But, I do agree, more developers would help, and we need an effective way to manage it better.

-Gabe

I agree that organization of this project at this point is crucial and that we do need to expand our bases for developers. As for keeping Jarad and Bill and most of the other developers on this project, I don't see that as being a problem. However I also agree that they deserve compensation for the great deal of work that they do for the project and personally I will be contributing to that by advertising my company on this site relitively soon. Also we may consider actually advertising the site on other forums to gain more support and a larger user base. This way we would be able to gain more donations and charge higher advertising prices to companys for the added exposer. Lastly if we can start incorporating other tuning programs (maybe megasquirt) and the ability to tune other manufacturers vehicles theuser base would be able to expand very rapidly.

- Eric

I can agree with pretty much everything said in this thread. Unfortunately, like pretty much every OS app, time is the problem. I've been swamped as things I've been pushing aside for the last year are catching up to me. I don't think much of anything has slowed down other than myself, and right in the middle of a major overhaul. I keep meaning to sit down and do some coding, but something always comes up.

At this point it seems to me it might be good to hand off being the project lead, at least temporarily, if someone is interested. I'm honestly pretty inexperienced at being a project lead (though I've been a lead developer for quite a while) and between the inexperience and the lack of time, it would probably be best for everyone. Maybe I could even share the duties with someone.

There have been a whole lot of people showing varying amounts of interest in helping out with the code. This overhaul was supposed to modularize things more and define interfaces and such, making it more friendly to multiple developers. Of the people who have started working on something, only a few have ever really panned out (but their contributions have been huge). Better organization would help, I'm sure.

Since I don't have the time to finish the huge overhaul I started, it might be good to have someone else take that over or split the tasks up some. I never really made any kind of design or anything, though, so splitting it up would be tough. If anyone would like to go through what I've done and hopefully get an idea of where I was going with it, please do. Its all in the RomRaider.newmaps package.

Thanks for your input! Things have been dragging a bit and I'm sure the users are getting anxious.

I know exactly what you mean by time being an issue.

What needs to be done to address that issue is to spread the load out.

I think we have enough guys involved and enough time spread between us to manage releases, but we first need to work out a plan.

Here's what I would do:

* Identify dev team (already done: http://www.RomRaider.org/RomRaider/RomRaiderTeam)
* Create a better dev communication medium - the forum just doesn't cut it. A mailing list would be great, IMO. All significant open source projects I've been involved with are centered around a dev mailing list. Forums are good for end users, but not so good for development.
* Document build process. (btw, I just noticed that 0.4.1 doesn't appear to be tagged in the tags dir)? Once this is done, other devs can easily create testing builds.
* Create/use some sort of bug tracking system to keep track and identify all issues.
* Identify short and long term issues/goals and stick them in the bug tracking system.

Once those high level things are done that will give RomRaider a clear picture as to what needs to be done and who will be able to do it.

As for short term and long term development:

Short term - There is a good deal of minor bugs in the current release 0.4.1 which have been reported (along with the usual Ecu Definition updates) I think it would be worthwhile to create a 0.4.2 which addresses these issues.

Long term - A big picture needs to be developed. Tgui's concept of pluggable tuning entities is good, IMO. jradams38 suggestion that the UI be separated as much as possible from the core code is also good but not always practical for this type of application. Then we have the issue of live tuning, etc...

All of these issues need to be documented somewhere for a number of reasons.

1. I find that having a list of items allows you to concentrate on things that need to be done.
2. Getting that list down and breaking the items down into manageable chunks of work does wonders for motivating developers. Without specific items it's hard to motivate a volunteer to do something.

If we can get these things rolling I might be able to motivate myself to start writing some RomRaider code again.

Ok, so we are all in pretty much agreement. I think the first thing we need to do is make the main split most organizations make on projects as they grow (bugfix team that fixes bugs in the latest releases and a new development team which ads features).

For new development, realistic targets need to be made with feature requests added often and relased often into Alpha/Beta test often. We will need a large amount of people willing to test these new features as well. Making them part of the team will help with this.

The code/bug control software that we use does not really matter. Getting people to join and organizing the people into test/dev/support positions will help greatly. People will spend more of their free time contributing if they are made "officially" part of the project as well.

So first, I think we should do this:

Make a posting about positions that need to be filled and when someone has the skillset we need for that position, make them an official developer/tester/user support/tech writer or whatever. Just having that next to their name will make them want to stay on the project. It takes a wide array of people with multiple skillsets to make any project succeed once it grows. RomRaider is at this point now. Getting people to do it for free and keep doing it is the biggest problem. The more people who can say "I was a part of that, look it says RomRaider XXXXX next to my username", the more people will contribute what they can in their free time. It also breeds a sense of accomplishment and pride for people who want to help out.

We need these positions (feel free to edit them)

Dissasemblers (Bill lead developer) - main skills: ASM, disassembly, ECU architecture knowledge.

C/C++ module developers, AKA flashing code, or anything else we need that will run cross platform and needs to execute fast with no or minor bugs. (I'll lead) - main skills: C/C++ kernel level development and I/O experience on multiiple platforms (Unix (FBSD - OSX - Linux) and Windows OS). These people need to understand how a bug in this code can fry an ECU very easily, so no C# only guys.

Java Developers (Tgui Lead perhaps?) - main skills: IDK.

Testers (IDK who would lead) - main skills: The ability to flash, log and interpret info to relay to the developers and manage a large amount of testers.

User support (IDK who would lead, but someone who has enough knowledge so this can be removed from Bill's plate). This person needs to be able to train support staff underneath him.

Technical writers (Braden, TurboMike?) - These would be experience tuners willing to share their knowledge with a tech writer and make a tuning guide that is comprehensive and in one place (the application would be the best place for it).

Marketing (???) - Needs to make stickers, banners, website design, etc. Can also lead a team of RomRaider user's and guide them in the proper way to push RomRaider while remaining friendly to closed source people like Cobb/ECUtek.

Each Lead would have a team of developers/testers/whatever underneath them and be repsonsible for distributing the workload on both the bugfix branch and the new release branch.

Above the coding/testing leads we need two project managers (new dev, and maintenence dev) and one Marketing Type/Project Manager to lead the whole show.

This might be overkill, but organization will get us traction. We have volunteers. Lets start officially signing them up, even if their contribution is just testing new stuff once in awhile.

Anyway, thats just my 0.02 ideas on it.

-Gabe

Everything sounds good. I think the clear division of labor is a great idea. I guess I'll direct my communication with Tgui, Lead Java Guy (if he wants it/already has it).

I can serve as a Java programmer. Tgui, send me a PM and we'll coordinate our efforts to finish the 5.0 UI. Even if the current state of work doesn't lend itself to multiple developers working on the UI, I can at the very least add comments or something.

P.S. - I think there should be a probationary period for new developers (even myself) where their code isn't immediately trusted. For instance, I could just email changes to my superior for right now.

Thanks,
J

Code reviews would have to be a must do by the leads, so I don't think any probation period is necessary. IMHO, if you contribute in any way, you should be officially listed as on the project. This keeps developers/testers/whatever on the project longer and breeds cooperation and not a rat race (like we all have at our day jobs). The leads would eventually end up moving into a code review/management role as the project grows.

The dev team is pretty close knit now, though once we get more people interested in contributing I'm sure a probationary period is needed. As of now, lol, well, if you can hack the app you're good enough.

I'd rather coordinate the completion of 5.0 in a new thread. Once you get the source and the application running in your dev environment, setup a thread with your questions concerning my NewGUI package (if you have any) and lets hash out some tasks and assign them.

I've got the UTEC side covered, what we really need is someone to take over the integration of the Eninguity ROM editing side. Crap, this belongs in the new thread I'll stop here.

Yah you java guys get out of here.

I got some C++ guys lined up to help me out.

I'm not sure we really need a Java lead, and I'm touched you think I could do that Man, touched is such a pussy word, "I e-punch you in the shoulder manly like."

I think there should be a team of leads that oversee various aspects of RomRaiders functionality. I don't know the rom side of the application well.

I know the newgui I'm writing, 3D, interpolation and UTEC code.

Kascade is the java guru of logging.

qoncept knows the current application and rom portion, though it sounds like he wants to give this up to someone else, maybe the OP?

drees, you want my 3d code? It needs some TLC!

In short, I'm working 3 jobs now and will be starting my masters program soon. I can be relied upon to support what I've done, but want no further responsibilities.

Awesome, we need some real C++ people here.

You saying I'm lazy?

Yeah I have some guys lined up who have some cross-platform exp, but I want to seperate the flashing routines from QT first and modularize it (the flashing is already class hierarchy based, which is nice, and its only a small amount of work, like 80 work hours or so from what I can tell looking at the code, but there are some places where it is not so neat and tied heavily into the GUI). Then it is being handed off for additions once I have a working command line flasher for JNI integration. This has to wait until this summer (being in school forever sucks when having to work full time), and I am being a bit selfish in wanting to do the initial port and re-design as I have done this many times in the past (its what I do the most at werk, besides brand new subsystem dev).

3 jobs? Damn you supporting an army? I just have a wife and kid to support.

Just joshin ya.

Well, 1 salaried job and 2 contract jobs. Contract jobs pay well No kids and no wife on my end. Though I tell the GF this money is going to pay off my car when in fact I need money for a ring. I R growing up. 'bout time @ 27

I got married @ 27. Yeah contract jobs pay well, but I have a well paying perm job and the wife doesn't have to work (family time important too), so... I keep going to school so I can get promoted and not just sit in the cube and code all day, although what I really want to do is sit in a cube and surf all day until someone has a problem they cannot fix and I go and fix it for them. Hehe, I am lazy at heart!

Wait I am sitting in a cube and surfing @ werk. I better do some real work now.