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.

Couple Things...

[metacosm]

• Q: 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?
• A: First of all, you explain what features you want in your HACKING file, and if they contribute something that you are not ready for, put it on the back burner. If they submit a patch you will NEVER be ready for, tell them that isn't what this project is about, it is YOUR project, they are welcome to have their own project.
• Q: 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.
• A: It is your project, you ask for a detailed explanation of what it does, and advice for getting it integrated, or, if you just don't like it, don't integrate it, they can start their own project.
• Q: 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.
• A: Forks are not negative, don't put them in that light, forks are a natural occurance when two people have different goals. It doesn't hurt your project, it allows people who have simlilar goals with you to work on your project, and people who have similar goals with the other project to work on it. If you program isn't scratching my itch, I am not going to work on it anyway, so don't feel like you lost me, someone else just gained me. You can't assume competetion, if the projects are different enough to generate a fork, they are different enough to get different types of developers with different goals.

-- Robert
please excuse speling and gramar ;)

Re:It may be too simple.

[neuroticia]

Plenty of open source projects start off that way, I don't see why you should get accused, so long as the project is going to become open source after the initial release, and so long as you don't change your mind after using the beta-testers time.

Too many cooks can spoil the broth, but as the 'broth' becomes more mature it can handle more cooks.

I would think that a good way to avoid the contamination of 'unwanted ideas' would be to clearly lay out the first few releases. "Release one will have... blah blah, Release two will have blah blah. After which Release three is open for suggestions."

On top of that, use your 'planning documentation' to direct the project. Lay out how you wish contributions to be coded, etc. Demand good documentation of contributed code, as it's easier to implement things when you have that 'map' of what's being done with the code. (verify that the code does do what the comments say it does!)

Just because it's open source doesn't mean that it can't be structured. In fact, open source is more likely to be structured because of the many contributors and wide ranging talents. A well-structured project is more likely to survive than a poorly structured one because it will be more appealing to more developers.

-Sara

Why do you want to open source it?

[SmallFurryCreature]

If you just want people to have access to the code for review then you don't need to opensource it at all. Then you can keep working on the code without people taking you're work and doing their own stuff with it (well not legally anyway).

Surely the whole point of opensourcing is to get input from other people. This may well include things that you don't need. The linux kernel has many patches and some projects spend a lot of time as kernel patch before they are ever added, if indeed at all, as standard.

As for forking, if you look around it doesn't seem to take place all that often. People who want their own product will usually want to start from scratch. Forks generally only take place when a very real difference emerges between the two possible paths. Of course youre software has to be really usefull first for this to happen.

But really the point is what do you wanna do? If you just wanna code and not be bothered by pesky outsiders wanting bug fixes for their crappy systems (Extreme 1) then perhaps you should just put youre code on a page and a note of good luck. Then again you may feel that two heads know more then one and you are looking forward to closing working with other developers to great together a brilliant product (Extreme 2). Decide on how you wanna run the project and then decide the appropriate license. Open source is a means, not an end.