First steps

1. Subscribe to the dev list and say Hi
2. Get the source code with svn or git
   • svn co https://svn.apache.org/repos/asf/openejb/trunk/openejb3
3. Build the code (maven 2.2.1 or higher recommended)
   • mvn clean install

Play around with the examples under the examples/ directory. Some of the neater ones are (ordered simple to complex):

• simple-stateless (see video)
• simple-stateful
• simple-singleton
• simple-mdb
• async-methods
• schedule-methods
• injection-of-env-entry
• injection-of-ejbs
• injection-of-datasource
• injection-of-entitymanager
• testcase-injection
• testing-transactions
• transaction-rollback
• testing-security
• testing-security-2
• simple-webservice

What is the process?

public void contributeToOpenSource() {

    boolean stillInterestedAndHavingFun = true;
    int taskSize = 1; // start small!
    
    contributing:
    while (stillInterestedAndHavingFun) {
    
        Task task = findSomethingInteresting(taskSize++);
    
        if (!task.hasJira()) {
            createJira(task);
        } else {
            requestToBeAssignedToJira(task.jiraId());
        }
    
        while (task.inProgress()) {
    
            chatOnListALittleGetCleverIdeas(task, new Ideas(task));
            hackALittle(task);
    
            if (task.tooHard() || task.notFun()) {
                // no big deal, try again with something else
                taskSize--;
                continue contributing;
            }
        }
    
        File patchFile = createSvnOrGitPatch(task);
        attachToJira(task.jiraId(), patchFile);
        askForReviewOnList(task.jiraId());
    
        while (!committed(patchFile)) {
    
            try {
                pokeAtSometingElse();
                helpOnUserList();
                dayDream();
            } catch (MoreThanAWeekException e) {
                // Assume it fell off the radar -- happens.
                // Evidence we need more committers.
                bumpThreadOnList(task);
            }
        }
    }

}

After a while when people feel comfortable with you as contributor, they vote you in as a committer and ... big surprise ... there's almost no change in the daily routine. You get access to svn and pretty much everything else stays the same. Instead of submitting patches, now you have to help review them and commit them. Instead of learning how to contribute to an open source project, now you have to learn how to help others get involved. And of course it doesn't happen all at once, you never stop learning these things and you never stop wishing you had more time.

No one cares how much code you can write or how fast you can write it. We all just contribute what we can when we can and there are no expectations on how much, how often, or where.

It's very much about the journey and there is no real end as long as you're having fun and learning.

Probably finding something to do when you do have time is the hardest part ... that never changes.

Be Brave

Don't assume everything has already been discussed a million times and you're the only one who doesn't know and so you shouldn't bother anyone and should just figure it out on your own. That thinking is your enemy. Don't do that or you will get nowhere ... very slowly. So slowly that now you feel you really can't ask about it because surely everyone assumes you know it or have done it by now. That thinking is a terrible trap. Ask questions. Post your thoughts.

Don't worry about asking "stupid" questions on the list – even simple questions have great value. They often lead to surprisingly good discussions. They also have a profound impact on the people around you, the ones you don't see.

...

Start small, get it checked in (or patch submitted) and work iteratively.

Things that always need doing

• Final variables & fields are preferred where possible, but a lot of the code is old. Feel free to add them and hand the code back.
• If you have any skills with code coverage tools, then you'll probably find way too much to do! Tests are always welcome.
• There are over a 1,000 TODO comments in the code. Maybe some should be deleted. Maybe some could be completed. They probably all should have a JIRA id on them.
• Pick a random class, see if you can figure out what it is doing and javadoc it.
• Add @Override where applicable
• Intellij has an 'Inspect Code' feature. Yikes does it produce a lot of output.
• No doubt there is some exception handling that can be greatly improved.

Obviously, one could get quite bored doing just the above. But sometimes the above tasks can lead to more fun and exciting things. Anything that gets you in and looking at code and actually touching and changing it usually results in questions, discussions and ideas... then little passions and late nights and lack of sleep and caffeine abuse.

Things to avoid

Huge patches

Huge patches are hard to digest. Try to avoid them whenever possible. Any step forward is a good one. Small steps allow people to see where you're headed and give input. That's true regardless if you are a committer or contributor.

Be careful with reformatting

Try to never mix logic changes with code reformatting. It makes it nearly impossible for others to see what the actual change was.

• If you are a committer and want to reformat something, do the reformat as a separate commit before or after the real change. As long as they are separate and clearly marked it should be easy for people to see what is going on.
• If you are a contributor and want to reformat something, maybe suggest it on the list, but avoid submitting patches that are just reformatting.