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."
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.
.
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.
We're Doomed
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)
Perhaps you should just code hard, add contribs you like, politely decline others, and drink lots of beer and/or bourbon when done :)
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.
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.
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?"
Sometimes it's best to just let stupid people be stupid.
I created a couple of open source programs. I have had very little feedback - a few suggestions for improvements, and a few people that say they use it (like the number of emails received can be counted on one hand).
I think that maybe your primary concern should be how to get other people to be interested.
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.
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.
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 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
Not exactly. He posted this to Ask Slashdot because he wanted to know what Slashdot thinks (not Google), and wanted the Free Software community to discuss this to possibly prevent problems in the future. By asking people a direct question, you can often learn a lot more than browsing a variety of scenarios and piecing an opinion together from too large a dataset.
I'm in this boat myself. I've been working on a project that's been publicly available for a bit over 4 years. Prior to that it was just a jumble of code that got used around the office.
I have never promoted it - it was just another link among many on my web page. Eventually people trickled in and found it, and started adding their own links. Google appeared during that time and the rest is history.
While this was going on, I've been slowly plodding through the list of things that it needs to have. There have been plenty of contributions, and a few that didn't make the cut. Nobody's been irked enough to fork it yet, so things have been pretty easy. I think the key here was that by the time most people discover it, there's a pretty solid design in place. It would take someone with a lot of balls to step up and call for demolishing it.
That said, you still should take a long hard look at patches that aim to change some fundamental technique. I had a developer send me a patch to completely rework some drivers. It wasn't taken directly, but it inspired a complete overhaul that replaced a lot of cruft. Sometimes the best contributions are the inspirations that come from seeing a patch that exposes a larger idea.
If you and the people who can contribute have similar goals, it should be a smooth ride. Otherwise, expect someone to go off and create another project to solve the problem differently. They may even use bits of your code. That's life - just try not to take it personally.
If you care about the original problem being solved, it may be for the best. You'll end up with a better solution and won't even have to worry about maintaining the code base any more. If you're only in it for vanity then you're screwed.
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.
I would have to agree with the parent -- the best thing a project can have is a detailed design document. Not only will it help you judge the progress of your program, set milestones etc, but it also helps to show other potential developers where you are going with the project. Basically it can help you keep your project on track even when a single stubborn developer insists that they do something their way -- you can point to the design documents and have a basis for rejecting their idea(s).
Never be so rigid as to refuse any change in the design document whatsoever, though. If many people are wanting a feature, or want to take things in a different direction, then you have the choice to incorperate that into your project, or sit by and watch them fork it.
Managing projects is always tricky and there just aren't rigid rules that every project should follow. Well, maybe this one rule.. always try to be rational and logical about things rather than emotional. It sounds a lot easier than it actually is -- programmers get attached to their code and their ideas, and it can be hard to influence them to change when they make up their minds. If you try to approach things with as little bias as possible (while keeping your goals in mind), I think you'll do well in most any project.
-Sou|cuttr
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
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...
...richie - It is a good day to code.