Open Source Politics - Maintaining Your Vision?

Theovon asks: "I have only released one open source project so far (link below), and I have never submitted patches to any other, so I am very unfamiliar with some of the politics. I have a new open source project I am considering releasing sooner rather than later, but I want to know how to keep control over it long enough to get into it everything I want. Specifically, what I want to know is how to deal with unwanted suggestions by contributors. By unwanted, I mean submissions which may be nice but which would cause the project to deviate significantly from where you are trying to head. I think it's important to publically address this issue, rather than doing Google searches and piecing together a perspective of it on my own. think there may be many developers out there whose work could benefit us all but who are wary of what might happen if they were to let loose before they had achieved enough of their goals. In my ignorance and paranoia, I have been pondering the various negative consequences of an early release, and I would like to see what Slashdot has to say about these concerns."

"First, what do I do when someone submits a patch that violates my 'mission'? Should I try to be democratic about it and try to add it? Should I ignore it? What should I say to the contributor?

What if I get a patch that I don't understand? Perhaps it is garbage. Perhaps it is over my head and too complex for me to see how I can integrate it and still see the structure of my whole project.

What if someone gets angry and decides to fork the project? Under GPL, they would have the right to do this, but the excess competition could be unbeneficial when it would have been better for the contributor to wait for me to be ready for their suggestions at a later time.

My one released open source project GTerm went fine, but that was mostly because I had only one contributor who contributed only because he want to use my tool to make his tool. Actually, it was mostly a flop, because there was very little interest in it that I could see.

I have had other (non-software) experiences, however, where people took my ideas and terribly misrepresented them and twisted them into utter confusion. People tried to 'contribute' but ended up just making a mess of things. Sometimes, it's very hard to maintain the integrity of something that you have worked very hard to build.

I don't consider myself a great visionary, so don't take words like 'vision' and 'mission' to be arrogant. I, like many others, simply have certain things I would like to express before I am ready to take certain suggestions. By 'finishing', I feel I am letting the world know what my ideas are and setting up a framework that others may find to be beneficial. Once a certain point is reached, I can let go, and people should feel free to do what they want. My goals, as an open source developer, are simply to share ideas. If those ideas, once fully expressed, are rejected or vastly mutated, so be it.

But I'm assuming that my paranoid perspective is completely wrong, so I am asking the Slashdot crowd to share their experiences with this and help me and others to understand how to deal with those who contribute, those who THINK they're contributing, and those who would interfere."

Comments

Be strong

[IamTheRealMike]

That's basically it, in a word. Remember at all times, that it's your project, not theirs. If somebody submits a patch you don't like, tell them so - but (and this is important) make sure you have good reasons for not liking it.

You say, what if a patch goes against my "mission". I'm not sure what you mean here, other than perhaps you have an instinctive feel that something is wrong. I say, don't worry about it. For starters, most projects debate patches before work starts on them, so you can usually veto an idea before it gets turned into code. Use this opportunity to steer things towards your vision.

One last tip: don't release too early. If what you're writing is complex, make sure the fundamental architecture is there, and make sure the rest is basically filling it out and hacking on it. If you just announce a vague idea, people are going to get involved who have very different ideas to you, and you'll either get pushed around or engaged in a flamewar. If you ensure you have the fundamental design there first, then people who don't like the design will push off, and those that do will (hopefully) stay to help.