How do you get over tooling problems in a communal open-source project?

Question

Two different teams (from different companies) are uniting to work on a communal open-source project. Agreeing on technical design is something we have no trouble with, but I'm struggling with tooling/workflow problems.

I really like a BDD testing tool called phpspec (analogous to RSpec), whilst a lot of my teammates stick to what they know (phpunit) regardless of the pros and cons of either tool. How do you move forward with a project when members are in disagreement like this? Should you enforce a standard testing tool? Is there a way of using both?

I think it boils down to whether members will break out of their comfort zones to learn new technologies that are better for the job. I'm of the strong opinion that you should always be willing to learn new things, but I get the impression that others are purely concerned with getting things done in the quickest way possible - thereby using tools they've used before.

Answer 1

I think you answered your own question; whilst you'd like to use 1 tool, "a lot" of your colleagues prefer to use something else. Without a 'boss' to decide tooling, the majority rules and you need to go with the preferred tool.

Now, there's no reason why you can't try to engage with them in discussion of tooling. You will have to take the initiative and lead the debate around changing, you will also have to persuade them to agree with you and that will take a bit of effort.

Think of this question from their point of view. Unless you collaborate with them, one of them might post a question "how to deal with one developer who insists on using a different tool to our standard?". How would you react if one developer decided to change a tool you have already agreed to use?

Ultimately you have to agree to use common tools, just like common design. If you don't there will be chaos.

Answer 2

I recommend you review the needs and decide on what tools need to be common. For example you can't have some people using svn and others using git when there is a lot of code sharing. However when it comes to editors, differences may be ok. The time, cost and motivation for people to switch tools that are essentially about preferences is often not worth it.

Some practical examples:

Need to be common:

• The database being used
• The language being used
• The source control system

ok to be different:

• git tools - gui's, cli, etc. The end artifact (code is in git) is the same.
• Editor - there are many choices here

An important factor is sharing is freqently the editor. Basically if folks are good in different editor you have to accept it initially. On an open source style project it's most likely that people will stick to what they know and are comfortable.

If you need to pair on code you have three options:

• One person does the typing and uses the editor are comfortable and proficient with.
• Both people use a very simple editor (notepad, gedit, etc).
• One person invests the time to learn the editor that the other uses.

My personal experience for editors (while working in the Ruby on Rails community for the last few years) is that people are fairly split between editors (usually between emacs and vi). When it comes to writing code or even pairing, it doesn't matter that much, as long as the person coding is proficient in their tool and the person watching can follow along and see the code ok.

In your case, it's more about tooling than tools per se perhaps. The issue about which testing framework (phpspec vs. phpunit) to use when writing code, that's certainly tricky. I think this comes down to what's going to happen as you move forward. Will each group/person ever have to read or alter tests written in another framework that they don't know? Open source collaboration frequently requires this. If so you'll need to reach agreement on the framework. You'll need to work through the difficult and often contentious discussions. It's best to start out with agreement on things... that you can agree on... such as 'we do need to pick one' and 'whatever we decide at the end of the discussion, we all agree to be bound by it', 'first thing we'll do is listen to each other carefully', etc.

For this issue of different tools, I would put my efforts into showing why my tool works fine instead of others. For example with editor, its the same output at the end anyway. If tests are used to generate code (i.e. tdd) and discarded after, their implementation is less important. If they are retained afterwards and used as regression tests than it probably makes most sense to use the same framework.

Answer 3

Every project needs some kind of central leadership to call the shots and make decisions like that.

In a company, this is usually the project leader appointed by management. In a large open source community, the leadership is often some kind of meritocratic community process where every participant can make suggestions and an expert group votes on them.

Your project appears to be somewhere between these two. Two companies are involved in equal parts, and letting one take the sole project leadership seems to be unacceptable for the other. But you don't seem to be large enough to justify a community process with all the red tape and paperwork involved.

One possible solution could be to appoint two project leaders, one from each company, who agree on a common workflow process together and enforce it in their respective companies.

Another solution would be to hire an independent project leader who isn't part of either company. This could be done by forming a 3rd company as a joint-venture which is owned in equal parts by both partners and has the sole mission to create that software. The only regular employee of that company would be an independent project leader. Your team and that of the other company would still be employed by their respective companies, but get assigned to work as contractors for the joint-venture. Both teams would report to the project leader, who in turn reports to the owners of his company (your respective bosses).