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

Define your goals

[srhuston]

Start by defining the goals you have for the project. Put your vision down in writing, and maybe a roadmap (version 1.0 should do this, 2.0 should do this, etc). This way if someone submits a patch or feature request that you think is out of the scope of the project, you can politely point them to the roadmap and explain why, perhaps saying that it's something to look for as you approach another milestone.

As for things you don't understand or things that you don't think would fit, ask the submitter why they think it should go in there, and basically demand an answer better than "Because I like it". If they can convince you that it's a Good Thing, then look into including it. If not, then there's nothing wrong with disagreeing.

And just because someone forks the code to get their features included doesn't mean they can't be merged later. If your software has a clear and concise plan, people will generally choose that over another project slapped together because the project admin didn't like their idea. Yours shows thought and planning, and as I said before if you decide later that the previous idea is a good one, you can always add it later.

Re:Define your goals

[g()()ber]

"If your software has a clear and concise plan, people will generally choose that over another project slapped together because the project admin didn't like their idea."

This is probably not the case. If the forked version has feature X that most people want, and yours doesn't, they'll take the fork. If the fork has www.programfork.com and you are member.isp.com/~you/program.html, people will find the fork. If the fork has a higher listing on google, people will find the fork. If Microsoft makes a fork and includes it in windows, people will use the fork. (Not to bash Microsoft, but people will often fork a program and include it with their own, and Microsoft is a common example.)

Re:Define your goals

[ryochiji]

> Start by defining the goals you have for the project

I would concur with that advice. Most people who submit patches understand how the Open Source model works, and they're usually not under the false impression that project admins have to incorporate all submissions. Also, if you explain why a particular patch or suggestion isn't going to be incorporated, the person submitting the patch/suggestion is less likely to take offence.

With my project (see shameless plug below), I was fortunate enough to have a fairly large company "sponsor" a feature for me. The difficult part, though, was to try and not be influenced by the "sponsor" too much. Even if you receive corporate backing of one sort or another, it's important to draw the line somewhere, and make sure they understand that they haven't bought you or your project. (In my case, the person I worked with on the other side clearly understood where we stood, so it was hardly ever a real concern.)

Another thing to remember is that people simply may not care enough to bother forking. I don't mean to be demeaning, but just want to point out the statistics. The fact of it is, most "Open Source" projects are written and maintained by a handful of people, with a slightly larger group of people testing (real testing, that is) and submitting patches. Although it may depend on the type of software, typical users aren't going to submit very many patches, or even feedback in general. For most projects, I'd say it's more likely for people to just stick with the project than to go through all the trouble of forking. But if they do fork, that's also not a bad thing (afterall, we're for competition aren't we?)

It's your project

[Anonymous Coward]

It's your project and you rule. If someone contributes you decide whether to make it part of your project or not. Maybe have a contributed section where contributed patches you don't want to integrate can be placed for others to play with as they see fit.

If someone is really desperate in twisting your project into something you don't care about or use, they can always take your code base and develop their own project upon it. Your original project will still be yours.

Makes sense? At least by sharing it others don't have to reinvent the wheel if your project mostly fits their need.

Adi

Open Source != Open Project

[Tank]

I think it's important to make the distinction between Open Source and Open Project. Just because you release the source under the GPL doesn't mean your project needs to be open to all committers.

In order to maintain control of your project, simply limit the number of committers to the repository to a select few you trust (or just yourself.) This approach has worked extremely well for the kernel source.

If someone is hell-bent on introducing something you disagree with, they have the option of forking the source and creating their own project, but this seems to be the exception and not the rule.

Benevolent Dictator

[Brian Hatch]

What you're looking to do is become a 'benevolent dictator' much like Linus is to the Linux kernel. That's an admirable goal, and one that works fairly well if you're up to the task.

Clearly defining the goal of the project is important. Take cURL for example. It is made to snag URLs and shoot the results to STDOUT. It has all the options you could need to support authentication, posting, etc. In fact, the majority of the code is in the library, not the command line utility itself.

Now folks say "Hey, let's make it a GUI application!" but the current maintainers say no, it's a library and a command line tool. However they've been saying that from day one. They clearly define what it is and isn't. It is not a wget replacement, and they don't want it to be. Folks will understand when there is consistency in the answers.

I myself briefly maintained Stunnel (stunnel.org) because the author was offline for six months and there were security issues that needed to be addressed. I didn't want it to be a fork, because I wanted to hand ownership back to the original author once he returned, and that's exactly what happened. He'd done a great job incorporating things that most folks needed.

That said, many people had visions beyond what Mike was willing to incorporate into the official version. Instead of dropping those patches on the floor, I've made them available at the website, so folks can apply them if desired. Thus there is still one consistant main version, but no problems if folks want different versions - just apply the patches.

You must be willing to listen and decide when you're wrong, and when the suggestions go against 'the plan.'

Good luck, and may you enjoy walking that line.

--
www.buildinglinuxvpns.net

interest

[DeadSea]

Most projects generate almost no interest (flops by your book). As an open source developer, if they work for you, what more do you want?

I don't accept any patches that I don't understand, or that I think will make the project harder to direct, maintain, or to make additions. If somebody wants to fork it is almost never a problem. If you think their patches will have problems, so will their version. If they want to do something different with it, then it really isn't competition. Why is competition bad anyway? Its not like you expect to make more money the more customers you get.

Read the cathedral and the bazaar if you have not already done so. You think like a cathedral programmer: your program should be directed from on high. A bazaar programmer will coerce others into feeling good about making contributions and release early and often.

Furthermore, you need to look at your motivations for producing open source software. You sound like you want the user base and the name recognition. It doesn't happen to all of us. I code open source because I want to make cool things happen and I want to force other people to let me experience the cool things that they make happen (for free!) So one of my favorites is why not lgpl?

If you want a successful (popular) open source project, the ones that make it big fall into two categories as I see it:
1) The ones that are big: mozilla, the gimp, they take a lot of open source programmers working together to produce something that paid developers would have a hard time doing.
2) Projects that let other developers build from them: linux, libraries, that fuel innovation in other open source developers.

If you work on something that falls in both those categories (like linux and mozilla) you are all set. But you can't do it alone. And unless you release early, and often, you can't get help.

Just look at Xemacs

[Fujisawa Sensei]

Want to know what happens projects fork due to politics?

XEmacs Vs GNU Emacs

In particular I find Richard Stallman's point of view quite enlightening on the GNU System and FSF.