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 ;)

Be Like Linus

[rootmon]

You know how people try to immitate people like Socrates, Christ, Budha, Gandi, etc, well you need to try and immitate Linus my friend. The self-styled benevolent dictator:
1) Be great at coding
2) Have an opionion about what's good for your project and don't compromise unless they give you a really good reason
3) Get a thick skin

Re:How typical.

[DeltaSigma]

The part I don't get about all the complaining that's done these days is that reading and responding to slashdot posts is completely optional. Someone obviously thought it better, for themselves and others of like interests, to collect what one expects to be high calibur opinions into one point of reference, rather than get a hail storm of vaguely relevant web pages. Naturally the editor probably thought it a valid point for discussion as well.

I'm also under the distinct impression that users may ignore any topic type they feel is not entertaining in some way via the control panel.

It's common courtesty to provide constructive feedback, or none at all. I, myself, have found this topic very informative. I imagine many other developers who are in the position of considering open sourcing their projects feel the same.

Hell, why don't you go have your fun looking up everything on google (everything we see on slashdot can be found there afterall) and we'll have our fun discussing these issues in a somewhat constructive manner...

Suggestions

[Spazmania]

What do I do when someone submits a patch that violates my 'mission'?

Its perfectly acceptable to ask the contributor to make changes to his patch before you integrate it into the codebase. Some will. Some won't. Don't sweat it. A change could be as simple as #IFDEF'ing the new code so that its only enabled if whoever compiles it specifically wants it os as complex as adjusting it so that it meets the "mission" you've defined.

If its a question of something that won't work after you make certain planned changes to the product, say so. The contributor might think your plans are a great idea and go work on them, saving you the effort.

If its a question of violating some policy you've set for the project, ask yourself a question: Does it hurt anything by being there disabled? If you're looking for strict control of "your" product, it will have to be "your" product, not "our" product.

And, if you *really* don't like it, the catch-all answer is: "I don't want to put that in the main code base right now, but I'd be happy to place the patch on the FTP site where everyone can get it."

What if I get a patch that I don't understand?

Doesn't Linus normally ask folks to submit changes as a series of smaller patches if something submitted is too complex? That seems like a good solution to me.

What if someone gets angry and decides to fork the project?

Aside from the blow to your pride, what exactly would the problem be? RMS notwithstanding, open source is a poor place for large egos. Just don't sweat it. Besides, if they did it in anger (rather than simply wanting to go another direction) then their project is likely to last only as long as their anger.

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

The Myth of Open Source...

[grumbel]

I think there are a lot myths and legends about Open Source which aren't really that true after all, at least not for each and every project.

Once you release a project, there won't be hundreds of contributions, there won't be hundreds of suggestions, there might not even be hundreds of users. In the majority of Open Source projects I have worked for, the real work is done only by a few. The project doesn't grow because of tons of contributions from outside people, but because of the work of the core team (and if that disappears, the development does simply halt). So in general I would say that nobody will fork, contribute or even suggest much until the project has really grown
very large.

When I compare downloads vs. mail and suggestions I get, I would say that that you need a 1'000 user for a simple comment mail about your programm, 10'000 for a useable suggestion or a tiny patch and >100'000 for a real contributions. To find a new maintainer for your project you need probally 500'000 or more users.

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.