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

It may be too simple.

[RumGunner]

If you want to avoid the problems of an early release, don't let everyone see it until it's in final form. Post to forums and ask for dedicated beta testers, and use their input instead.

.

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

It is yours

[Quantum Singularity]

Since it really is your project, you can judge what code to put into your project. However, you did make your project open-source, and it's free for the taking. We all agree to that when we open source, and that's what makes open-source work.

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

Start with Humility

[caferace]

If you go into this with the complete understanding that there are likely people that will eventually have a better grasp of your project (and maybe even code) than you will you'll probably not fret so much.

Of course, this is assuming your project will be interesting enough to attract smart people.

Re:Start with Humility

[gentlewizard]

I had a real world (i.e., non-code) experience with this recently. I started a project with a certain vision that was too big for me to implement alone. As I found partners willing to work with me on it, there was a clash of ideas as to where we should go. I gave in sometimes, stood my ground sometimes, and the result turned out pretty well.

I'm convinced (now) that had I held true to my original vision, it would not have turned out nearly as well as the team's vision did.

State your goals.

[dex22]

You could write a "business plan" and make it your Mission Statement, and clearly state that patches or submissions that defy or distract from the core project can't be accepted to the main tree.

To allay worried of people forking your code, why not help them? Ok, so you don't want to incorporate the patch, so publish it anyway as a patch, and your code, with an extensive patch library, will be much more interesting to other users, and may actually become quite popular ;o)

Keep control of the project as it's founder.

[IdleTime]

I think the best way to control the direction of the project would be to have a plan of what is going into which release.

If you end up with a lot of developers working on the issue, I would suggest that they submit their plans for enhancements, corrections, etc and that you and the other developers discuss it and agree upon a schedule.

In case of disagreement between the devleopers, you have basically 3 ways of handling it:
1. Ignore it (not very good)
2. Excersise founder rights and decide what to include (Linus style?)
3. Have the suggestor implement it in a branch, test it out and discuss it. (Better, as it will demonstrate its usability and functionality to you)

Having a mailing-list for developers to discuss issues like this is also a good idea!

In any case, good luck with your projects!

build to satisfy your needs not to compete

[natefaerber]

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.

What do you mean "unbenificial"? If you decline a feature or contribution and that person forks off, just keep on trucking with your original goals. By the time you are ready for that feature, he/she may have the bugs worked out in their new project and you can implement it more easily. In the meantime, you have a project that satisfies your needs at that time.

I don't think dominating a certain space is a goal of Open Source development.

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.

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.

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

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.

Whoa, cowboy!

[Wumpus]

My advice: Take a deep breath. Relax. Drink some alcohol, or smoke a joint - you worry too much.

In most likelyhood, nobody's going to give a shit about your project, so you have nothing to worry about. Most people just download the code, compile and run it, and you never hear from them again. If somebody comes up with suggestions you don't like, you can either explain why you don't like their suggestion, or suggest that they implement it themselves. It's perfectly OK to tell people you don't like their work for some reason, as long as you make an effort to understand their point of view, and they understand that.

Offer to host patches that you don't like, as a way of saying "I may think your features are silly, but I respect your right to write silly features - I'll even point people to them!"

You worry about forks - they don't happen very often, you know. When they do happen, they tend to happen for a reason. Should you care? I wouldn't.

And drink plenty of beer. It really helps.

Grow some balls

[Reality Master 101]

Step 1 is get over the attitude that you need to keep everyone happy. It's your project, run it the way you want to. It doesn't mean you have to be impolite, but just preface every e-mail with "thank you for your interest and submission, but..."

If someone's code isn't good enough, send them a message that says, "I'm sorry, but that patch doesn't follow the style that I'm trying to enforce for the code."

If the patch takes it in the wrong direction, say so. If you don't understand the patch, then chances are it wasn't documented well enough. Say "I'm sorry, but your patch isn't documented well enough for me to understand. I only have so much time to look at patches.

There's no reason you have to accept everyone's contribution. And if someone decides to fork the project, so what? If it's better, then maybe they're doing you a favor and you can use it (and perhaps fork it back in the future). If not, keep plugging away at yours, since presumably it's something that you want.

But the bottom line is to write code that pleases yourself, and don't worry about pleasing others. To be honest, I have a feeling that this question is really, "How do I get people in the community to like me so that they'll see me as one of the 3l33t?"

Maybe the GPL isn't for you

[shoppa]

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

Maybe the GPL isn't for you. You don't have to be angry to "fork the project"; anyone can do anything they want with the source code, as long as they follow the GPL license.

You don't have to use the GPL, unless you're already using GPL'ed code in your project. The last thing a GPL'ed project needs is a whiny controller who insists that those who disagree with his vision are angry.

Open Source punditry vs Control

[Logic Bomb]

I feel that the best projects have a guiding vision channeled through an individual or small group. However, I think it's useful to point out that from a philosophical perspective the whole point of Open Source is a total lack of control. Think of it from an evolutionary/capitalist perspective: if your project provides the most value, and doesn't run into any logistical/political problems that torpedo it, contributors will be happy to continue with your vision. However, if someone has a better idea, his *should* come out on top. Put bluntly, from this perspective you have no right to be in charge if you aren't the best person for the job. If the project's vision as you see it is guided mostly by what would make it most useful for you, you'll just have to hope that many other people share your needs.

always give rapid feedback

[Tim Fraser]

Hi.

I had a GPL'd project that was fortunate enough to attract the contributions of a small handful of generous people a while back. In one case I handled the contributions well, and everyone was happy. In another case, I did not handle it well at all, and I feel bad about it to this day. Here's what I did; perhaps my story will help you out:

The project was so closely intertwined with my real-life job that I found myself leaving it untouched for long periods of time as work dragged me in other directions.

One patch I got was a clear win. It came during a period in which I had time to integrate it quickly, so I did, and made a new release. This was a good case - it made me feel happy and I hope it made the contributor happy, too.

However, there was another case where the patch wasn't so clear a win. I thought I could implement a better solution, so I didn't integrate it. Then, I got dragged away from the project for a very long time.

I never wrote back to the contributor - I didn't want to create bad feelings by criticizing his solution, so I took the easy way out. (Mistake.) Ages later, I announced that I was stopping work on the project because I was changing jobs. The contributor was pretty upset that I hadn't used his patch in all that time.

So, my advice is, if you're given a patch that you don't want to use, don't use it. Tell the contributor what's wrong with it right away. Saying 'no' to someone may be hard, but leaving them hanging is worse.

Look on the good side, if your criticism is constructive, perhaps they'll fix their patch so you can use it.

- Tim

As much as they don't want to hear it...

[smoondog]

As much as some /.'ers might not like to admit it, a license agreement is just that. If the GPL doesn't fit you right now, don't use the GPL, use something (or write something) else that gives you more control.

It shouldn't be hard to modify an existing LA to meet your needs. If your project is useful, they will still come.

-Sean

Be a civilized bastard.

[Rimbo]

The only thing I have ever seen Linus Torvalds take credit for is being a bastard.

I think what this means is that he dictates the terms for contributions to Linux. He ultimately decides what goes in and what doesn't, and how patches should be submitted. There is no one sharing this responsibility with him. Ultimately, despite the thousands of people who have contributed to Linux, and the projects beforehand (such as GNU) that made these steps possible, the Linux kernel is still very much under Linus' control.

There is obviously more to it than that, but not much more than this:

I heard an interview with Linus that was on NPR about a year or so ago (it was posted to slashdot at the time) where he made this claim. That is, the claim that he is really just a bastard. I laughed -- I thought it was hilarious, because he certainly didn't SOUND like a bastard. He sounded like a very nice guy, very polite -- someone I would like to work with.

When Google posted their "moments in Usenet history," I found the flamewar between Linus and the author of Minix revealing. All through Linus' posts, even in the flamewar, I get the sense that he's not out to discredit or belittle the author of Minix, but to disagree more civilly, and in the face of some pretty harsh criticism.

I have never submitted anything for the Linux kernel; however, if I did, I get the feeling that if Linus wouldn't want it, he wouldn't put it in. I also get the feeling that he would not reject it in a way to make me feel rejected.

The proper way to do this is by giving credit to the person for the idea and the effort he or she has put in. Ultimately, you are the one who benefits from his or her work, so give them honest and sincere appreciation for that. Then, tell him/her that you want to wait before adding the patch to the software. And if anyone has an idea but no patch, ask them to code it up for you! Give them a challenge!

I believe that, aside from the fact he picked a project that millions of people were interested in, his civil authoritarianism has been the reason for Linux's success.

So take this to heart. Be friendly and appreciative of everyone who contributes, but ultimately be the one who makes the decision. The benefit of being a civil bastard is that people will enjoy working with you, and you will be able to maintain your vision.

From My Experience

[Bob9113]

First, what do I do when someone submits a patch that violates my 'mission'?

Step 1 is to reconsider your mission. When person A and person B disagree, person A is only right 50% of the time on average. Think carefully whether the patch can contribute to the mission, and whether it is possible that the mission itself should be patched. There's nothing wrong with vetoing or delaying an inappropriate patch, just be sure to understand and appreciate the patch before denying it.

Should I try to be democratic about it and try to add it?

If it is truly going to side-track or derail the project, you should table it, at least for the time being. Part of your job as steward is to make those decisions - and to make everyone feel good about them. Make sure the contributor understands that you appreciate the contribution, and will keep it in the list of suggestions.

Sourceforge lets you publish patches along with the project. That way you don't have to alter the trunk, and you can still publish the contribution.

Should I ignore it?

No. Graciously acknowledging people who are trying to help is good policy, even if you decide to veto or delay the patch.

What should I say to the contributor?

Start with, "Thank you for your submission!" Then briefly address your decision on including the patch, or ask questions if you don't understand. End with, "Thank you again for taking the time to submit!"

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

Ask the contributor to explain it. Open Source hackers love to talk about their code. It's like a motorhead's '67 Camaro. There's no such thing as asking too many questions.

Perhaps it is over my head

This is the best part of Open Source development. Learning from people who have had different experiences than you (not necessarily more or better experiences, just different) is extremely valuable. I have learned a lot from books, but far more from friends.

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

If you are genuinely appreciative of those who offer to help, and make all reasonable efforts to include them in the process and understand what they have to offer, this will not happen.

In the extremely unlikely event that you find a person who is completely unreasonable, he or she will not be able to maintain a successful fork - all the other contributors will be working with you.

My one released open source project GTerm went fine

Your next one will be even better. If you are a sincere and appreciative steward, you have nothing to fear. Have faith, take a chance on your fellow geeks - the rewards will more than justify the risk.

Wishful thinking

[richieb]

If you are really, really lucky you may have some of the problems you describe. Most likely no one will submit any patches to your project, so your "vision" will be safe. Most likely, no one will use your program either.

Actually, what you should do when someone requests a change or submits a patch, accept it and be grateful that someone spent time trying to improve your code.

One of the purposes of open source development is to encorage participation so that many different ideas can be tried.

Remember, Linux started as a terminal emulation program...

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.