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
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.
Don't publish until you're ready. Besides, more complete projects tend to gain more developer interest than pre-alpha code.
But once you release the project, you're not in control anymore. Basically, you'll have to give reasons behind your code and hopefully your team will be able to figure out on what is The Right Way.
(not that I am speaking from experience)
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)
Along those lines I may have to release a GPL version of my electric weasel.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
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.
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.
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.
-- Robert
please excuse speling and gramar
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
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.
You explain ahead of time, in the README, what kinds of contributions you are interested in and what kinds you aren't. You might even say "no patches accepted at all". Of course, how much you accept relates to how much benefit you derive from open source.
If someone sends you something you aren't interested in, you thank them but are under no obligation to include it. You put in the work to maintain the code all by yourself, you ultimately decide what goes in (it's more complicated for projects maintained by multiple people). If someone else cares enough about it, they can fork the code and make their own distribution (that's why it's open source).
If you don't want the possibility of forking, release the code under a more restrictive license initially. But I think people generally overestimate the probability or risks of forks.
"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?"
;-)
:-)
:-)
Good luck, and thanks for contriburing to the community.
I would just be honest. "Thankyou for your hard work, but this good idea of yours really doesn't bring Foo in the direction that I was targetting."
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.
That is unlikely to happen often if you know enough C (or whatever language) to have written a significant project in the first place, unless the patch is poorly written (hard to read, not necessarily a poor algorithm). In either case, if it isn't obviously a joke or something from a "Teach yourself C in 24-hours" background, I would politely ask for an explanation of what the code does. Having the original, you can always patch your code and see for yourself, but you never know what surprises may lurk in the depths of some of those patches.
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.
This is when your diplomatic skills come into play more than your coding skills. If they really want to fork it, well, they will fork it. Most of the time, I would imagine, you can have an intelligent discussion and possibly compromise to avoid the fork. If it is ultimately forked, that is when your competitive skills come into play. Crush the competition like so many grapes, but by making yours better and more focused (not by pulling a Microsoft!
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.
Most non-major open-source products have few contributors but the main author. This is a blessing and not a curse, unless the project becomes overwhelmingly large. Usually by the time that occurs, as it did with Linux, there is enough interest that those with other talents will be able to help. Then you can deal with the issues in question.
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.
Remember that you can refuse or even ignore any number of patches, be they good/bad/confusing/brilliant/whathaveyou. If the going gets tough, just think that Linux and Cox have it much tougher. How many bizarre patches do they have to turn down? What would Linux be like now if every one with a semi-good idea were accepted? I don't even want to think about it. It is your project, and if someone really wants to add something that mutilates it, see the "forking" section above.
Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
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.
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
"As flies to the wanton boys are we to the gods; they kill us for sport." - William Shakespeare, King Lear
Probably the best thing you can do for yourself is to keep a an open mind to submissions. Additional features that don't compromise your core agenda can turn out to be assets, Every so many revision cycles you can do a cleanup pass to prune out the superfluous side features that didn't prove themselves over time.
I would recommend keeping firm but open-minded control of exactly what goes in. Don't be afraid to say no. I don't see a fork in the project as being a threat most of the time. To reder it more or less harmless, register a trademark on your project name, so that the fork will not confuse your users. If their fork thrives more than your own, maybe their ideas were better than you thought. In which case, you can probably merge the two forks into a stronger project. Competition is good in the free software world. It takes nothing from you, while pushing the ideas forward more swiftly.
If you get code you don't understand, get the contributor to document it, and justify that the decreased legibility and maintainability will be getting you something worthwhile, instead of some miniscule outer-loop time savings. All of the teachings of well-documented, maintainable code count double in the open source world. I'd recommend writing a code style guide, and using it to solve diputes involving quirky style.
Don't incorporate patches that you don't understand or don't think fit the vision. That part is easy: just state your vision clearly up front and then stand by it. People will respect you if you apply it consistently, but you have to communicate and elucidate.
What is sometimes hard for people is to get by the "Not Invented Here" psychological problem and to loosen up and accept good patches that weren't expected.
If you are afraid of forking, you shouldn't release with an open source licence. Forking is what gives other people the confidence that you go loopy and start acting like a jerk that the work they put into your project won't be lost. If you want your project's code to be of the highest quality you have to be good enough to lead even though people might want the project to head a different way. Generally, if you are fair and do a good job of accepting good patches, forks will always merge back.
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.
Its probably wisest set to have the features completely modularized. That way, you can include alot of features as optional -- not necessarily installed via standard install -- but not necessarily make your program bloated.
social sciences can never use experience to verify their statemen
We have seen this in action most visibly with the Linux Kernel and Linus's control (and the resulting arguments about VMs, etc). But it is his strong leadership that has kept things (mostly) on track.
I have seen this in my own projects, and my rule of thumb is that the submitter must convince me to add their code. They have to sell it to me, explain why it makes the project better and moves it forwards.
You have to remember that it is your project, and that you have the final say. The submitters are always (in my experience) very nice, and most don't expect you to integrate their patches at all.
If you forsee a problem maintaining the direction of the project, maybe you should wait until you have a stronger framework in place before releasing it.
Good Luck,
Brian
Remember Lexington Green!
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
I wouldn't worry about it. When your project is at a stage you feel comfortable with the source and the functionality of the program, go ahead and release it, and let others do with it what they will. If they submit patches/features/ideas, use them or don't use them as you see fit. You're more than welcome to contribute source to the masses without any expectations of continued support. Thats the beauty of the open source philosophy. If the original authors don't want to/can't support it, someone else can pick it up and run with it. If it forks, so be it. Obviously the project is for you. Make it into whatever you want it to be. If others have a different vision than yours, they can fork it into a new project with different goals, and in the end, everyone has benefited. Or they can use features from your program in a completely unrelated project. Or you might inspire someone to create something new, even if they don't share your code.
In any event, when the program (and you) are ready, release it to the world, and worry about maintaining the program with submissions from others if and when they come in.
-Restil
Play with my webcams and lights here
"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?"
Just explain how you feel about the patch, and your reasons for not wanting to include it. They can always maintain their own fork with their own patches, even if you don't like them.
"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."
Ask for clarification? Apply it and run the result in a sandbox to see what it does.
"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."
Tough luck, you can't do anything about it. You can maintain your version, and they can maintain theirs. You can take code you like from theirs, and they can take code they like from yours.
It's really not that hard. You take what you like, code what you like, and others do the same.
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...
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.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
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.
Use the GPL or bsd license so that they can do what they want to the code and you can do what you want with your tree... if you like it use it...
The question I have is are you writing this for you or for others? if it is for you then screw everyone else and make it the way you like, if you want others peoples input then you will just have to figure out what features you want... sourceforge has a good way of allowing people to put feature requests and bug reports and things like that in so that would be where I'd host a project that I expected feedback on....
my feeling is if it is a one man project then make it what YOU want and if someone requests a feature that is not hard to implement or you like then add it is not then don't.. it seems pretty simple to me...
Only 'flamers' flame!
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
Just as a heads-up in case you haven't tried the "fork per version" approach in anger before: it works great, until you want to merge changes back in. Then, if your forks have deviated significantly from the mainstream (and if not, why bother?) it can really suck to merge things back in cleanly, and get everything properly regression tested to make sure they haven't broken your assumptions or vice versa since the fork.
[By the way, and entirely off-topic: has anyone else noticed that hitting "Preview" gets 404s back about every other time recently, with the annoying side-effect of losing your post if you forgot to copy&paste it first in several major browsers?]
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Open Source Politics - Maintaining Your Vision?
Well, I would venture that spending less time staring at the computer monitor would help maintain one's vision. Being political takes a lot of time and a lot of squinting, reading long documents and posts. Sheesh! Save your eyes!
Why bother.
That's a laugh. Although, perhaps a better way to state it would be well familiar with the topic of interest. Afterall, who better than Slashdot users knows about starting a project on freshmeat, working on it for a few seconds, doing your best to lord the miniscule authority over others, and then abandoning it after the website is (horribly) designed and version .001 is at a buggy stage of completion.
Ceci n'est pas un post
Forking is hard, especially for a large project. And even if there is a fork, you can at least benefit from work in both trees.
What you need to worry about are the guys who submit bugfixes and get stonewalled. They might not fork the tree -- after all, they've GOT the bugfixes. Why do they care if no one else does, when the committers won't apply the diff? CVS makes it easy to have your own tree that lacks several of the crashes of the released version, and continue to track everyone else's work with `cvs update'.
In fact, after doing this for a while you learn that eventually the bugs you fix bother someone who can commit changes, and they re-invent the wheel, and CVS is fixed. So after a year or so you can even get rid of your tree.
First, what do I do when someone submits a patch that violates my 'mission'?
Thank the submitter for their interest in the project, politely inform them that the patch will not be accepted, state the reasons why, and don't accept it.
What if I get a patch that I don't understand?
Ask the committer for documentation, code comments, or similar. If you still don't understand it, don't accept it.
What if someone gets angry and decides to fork the project?
So? What's the problem? Let them fork.
A Government Is a Body of People, Usually Notably Ungoverned
I've done maybe 20 previews here in the past 3-4 days, and no 404s (and BACK works fine in NS3.04, used that today in fact when I accidentally went somewhere else before I was finished). You sure you don't have a wonky route or something? Note: I do use Slash-Lite.
~REZ~ #43301. Who'd fake being me anyway?
You want to maintain control, but you want contributors to contribute code back to your project, on your terms.
No matter how you slice it, you are trading a degree of control for contributions; participation in your project is going to be inversely proportional to the amount of control you insist on keeping for yourself.
In the purest sense, a contribution of code *is* an asserion of control over the direction of the project as a whole, and it is one of the major incentives for contributions in the first place.
This would be a lot easier to explain if you had contributed to other projects, so that you could ask yourself what you got out of contributing to them: because that's exactly what contributors to your project are going to expect to get from their contributions.
It would probably be a good idea, at this point, for you to put in a month or two of volunteer work on someone else's project, so you could answer that question for yourself.
-- Terry
If your asking about politics and how you should behave then your already half-way to failure.
What's great about Open Source? Its all for fun. Don't worry about anything. Write code, release it, and do what you want.
It's really that simple. That's why people like Linus so much, he's all about having a good time. That's the only thing that matters.
int func(int a);
func((b += 3, b));
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.
If someone is passing you on the right, you are an asshole for driving in the wrong lane.
From my experience, project ownership is a big thing in the open source community. If you are running a project, it is your project. People will usually value your input over any other voices. Normally you must be a very bad project maintainer for a very long time in order to provoke a fork.
The key to successful open source project management is the project's mailing list. It is essential that you review patches and contributions rapidly on the list, and comment on them where necessary. Also, if there are patches you do not understand, they are neither properly written nor commented, and should not go in at this point in time. Hand them back, and ask specific questions, let the contributor rework the patch.
Finally, if you have a vision, or goals with your project, you probably have a whitepaper which explains them, and the architecture you plan. If you haven't, you do not have a vision, but some vague plans. Writing the paper will help you to flesh out these plans and produce a clear development target. The paper should be long enough to communicate your ideas and sync your contributors with your plans.
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.
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.
rule 1:
- I am right. Always.
Rule 2:
- When i am not right rule 1 goes into action.
-- Bastard's rulebook
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.
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.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
With closed source (even if the source is viewable by others) one is much less likely to get major contributions from others - why would they want to help if there is little guarantee that their work will be available to others in the future?
Similar arguements can be raised against releasing under a unique lisence rather than one of the well known ones (GNU, BSD, etc.) that people are more likely to be familiar with.
It could be IE6 at fault. I've got it in default condition on an unpatched XP machine, and have found it behaves all sorts of weird. Frex, it thoroughly mangles M$'s own KB pages when viewing saved local copies.
;)
Maybe it's some newfangled HTML copy protection
~REZ~ #43301. Who'd fake being me anyway?
Here are the conclusions I came to:
- I would use the QPL as the initial license. Since the QPL is an open-source license, but requires that changes be distributed as patches against the original distribution, this should discourage code forks (although they're still possible) and make it clear which code I've "blessed" and what code is modified. (I don't want to be blamed for a bug someone else introduces...)
- Ultimately, I expect to switch to another license (probably an MPL/LGPL/GPL triple license a la Mozilla), but not until my project is sufficiently well-established that it can't be trivially eclipsed by a forked project with a more active maintainer using my own code to compete against me.
- For now, I want to maintain a tree which is 100% my own code, both for "vision" reasons and as a potential demonstration piece for my programming skills. However, I don't expect this branch to last forever; once my initial vision is "finished" enough and up to my own quality expectations, it will no longer be important to have 100% of the code written by myself.
- Meanwhile, if others contribute worthwhile code, I expect to branch a new "community" version which will include code contributed by others, as well as my own code. This version would probably become the recommended version, and I'd probably have to work harder to apply my own changes to both branches. (Rather than branch a new version for this, it may take the form of branching the "100% mine" version and considering the mainline version to be the community version.)
- I won't accept code (even for the community branch) that is poorly written or seems to fundamentally conflict with the rest of the project. However, I will happily maintain a "contrib" area of patches that I choose not to integrate, so others can apply them if desired. (Hopefully, this should reduce the incentive to fork the project, also.)
- For worthwhile code contributions that constitute an unwanted shift in direction for the project, it may make sense to create a new branch for that purpose, rather than rely on "contrib" patches on sources that are likely to diverge. (In this case, someone would probably need to volunteer to maintain the branch, if it's not one I'm personally interested in.)
- I decided that it is critical that (potential) contributors never be ignored. Ignoring a contribution is worse than rejecting it outright. A rejected contribution (with constructive criticism) may lead to new and better future contributions, while an ignored contribution is likely to lead very quickly to the loss of interest by that contributor.
- If a patch is incomprehensible, a discussion with the contributor is in order, and perhaps a rewrite as well.
- If someone forks the project, so be it. Hopefully it won't happen, but it's always a risk. It's more of a risk early on, which is why I'm using the QPL for now.
- I decided to treat the project as if it might be used for "production" use, on general principle. However, rather than the simplistic (and somewhat ineffective) even/odd numbering approach of the Linux kernel, I decided to take a different approach to version numbering:
- Most importantly, I decided that no release will ever be declared "stable" without spending some time out there as a "release candidate" first, to allow time for any bugs to be found and reported. The "stable" release would therefore be virtually identical to a previous "unstable" release candidate, except for the version number and perhaps small nonfunctional changes like documentation No code changes should be introduced as a "stable" release. (This has caused too many "brown-paper-bag" releases in the "stable" Linux kernel series in the past, for example.)
- To distinguish "stable" from "development" (unstable) releases, I decided that the "stable" releases would be all-numeric (e.g. 1.0.0) while "development" releases would always contain alpha characters in the version number (e.g. 1.0.0.beta.3).
- To distinguish various levels of stability and approach to stable status, I decided to use word tags like "experimental" (maybe "exp?), "devel", "alpha", "beta", "rc", etc. This would be followed by a sub-release number in the same group.
- For development releases, I decided to use the next target stable release number as the base, hence "1.0.0.beta.3" precedes "1.0.0" instead of following it. (Of course, "1.0.0.rc.1" would be in between those.)
- In the case of branches for experimental coding, I decided to use named branches rather than a numeric branching scheme. Hopefully, all branches would start from a stable release, although I suppose they wouldn't have to. (I'm not sure exactly how to number named branches, but starting with the base revision of the branch point seeks probable.) If a branch looks like it will become long-lived and separately maintained, I imagine it would migrate into a new subproject name for the codebase and become the mainline version for that subproject.
- I decided that binary distributions (e.g. RPMs) should be offered for "stable" releases only, not for development releases. (Release candidates would probably be an exception, offering binaries temporarily, until the next release candidate or stable release, since they're intended to be stable releases and should be tested by non-developers...)
- I decided that the cycle between stable releases must be kept short to ensure that development never diverges far from the last stable release. If a non-developer wants to install a development release, that's a sign that the stable releases are too far apart!
- I decided that development releases would come with patches against the previous development release, but that stable releases would come with patches against the last stable release instead.
- I decided that a CVS server should be made available for people who want to track the development without having to download each development release or keep patching.
- I decided to cryptographically sign each release to ensure its integrity.
- I decided that I should have a bugtracking system (like Bugzilla) and place a high priority on fixing any trivial bugs to try to keep prople from getting discouraged when even the simplest bugs they report don't get fixed. Ideally, the bugtracking system should allow for easy integration with bug reporting via email.
- I decided that there should be at least two mailing lists (an announcements list and a developer's list), in addition to Freshmeat announcements of releases.
- I decided that the project should have a website, ideally one which has frequent updates (i.e. news items) every day or three. (There's nothing more boring than returning to a website to find that nothing has changed!) Screenshots are also good, if possible -- people love screenshots!
Unfortunately, I haven't had the time to get my project into the shape I want -- the website is woefully inadequate right now (ugly and too static), there's no bugtracking system or mailing lists yet, I don't have a CVS server available yet, and I haven't gotten to the point of declaring a "stable" release yet. But I've been announcing the few releases I've made on Freshmeat, and signing the releases for integrity, and using my version numbering scheme (which I'm tuning as I go; it's a work in progress), and I've got a demo server running. It's coming along, but it takes a lot of work, and I never seem to have much time. Of course, this is exactly why I used the QPL, because I expected to be less active at maintaining the project than I ought to be...In the end, I'm just making this up as I go along. I'm sure I'll make some mistakes, and others may not agree with every decision I make, but I choose to operate in the "benevolent dictator" model, not a "democratic" model. I reserve the right to be arbitrary and capricious, though I'll try not to be. Anyone who doesn't like it can fork the project, just as someone could fork Linux if they don't like Linus as benevolent dictator.
Of course, this is largely a moot point so far -- my project has generated very little interest yet and no contributors at all -- which seems to be the norm for small open-source projects. But I figure I might as well try to figure out some "best practices" from the start as I go along rather than wait until things get out of hand to start trying to implement them after the fact...
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay