Slashdot Mirror
Open Source Politics - Maintaining Your Vision?
"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."
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.
Three dits, four dits, two dits, dah!
Radio, radio, rah rah rah!
Of course, this is assuming your project will be interesting enough to attract smart people.
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)
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!
If you mod me down, I *will* introduce you to my sister!
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.
-- My HARDWARE, My CHOICE.
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.
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.
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.
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.
Stop-Prism.org: Opt Out of Surveillance