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
...rather than doing Google searches and piecing together a perspective of it on my own.
Isn't this rather typical of all Ask Slashdot submissions?
Why bother.
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)
Write out a clear directive for your project before you start, and start writing design docs soon after, so that it's clear what direction you are trying to take the project. That way, when people make suggestions that are 'unwelcome', then you can have a clear reason to let them know why, and then let them know they can either give a go and implimenting it in a clear way, and submitting patches, or some such to that effect.
I'd suggest not turning down ideas and patches that you feel are 'unwelcome' without a clear design that shows why it would be impractical.
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 :)
Life sucks. If you release open source, then one of the "drawbacks" is that you don't have complete control over where it goes. Your only option is to either try and subvert the vision of others to your way of thinking, ie. show them how, yes, you have thought of what they are suggesting, but it doesn't fit into your larger picture. Or you have to just keep ahead of them on the curve. Which, as everybody knows, may be hard to do. Especially if your ideas are not as "sexy" as theirs (according to some definitions of "sexy".)
Of course you do have copyright on the name/product, and and require that anyone who forks, does so with a significant and obvious title change.
Its your code. Most of the lamo suggestions wont come in the form of a patch.. more of someone whining for something. The good news is those people dont code.. so you can ignore them. You simply reply, 'Send me the patch, Ill review it.' that will scare off 90% of the poeple. The last 10% wont take to you shitting on their patch well.. point out stuff like style and other problems with it. Of course if you like the patch you can always accept it. You need a spine.. OS wont give it to you.. stand up and be a man.
It's your project and you rule. If someone contributes you decide whether to make it part of your project or not. Maybe have a contributed section where contributed patches you don't want to integrate can be placed for others to play with as they see fit.
If someone is really desperate in twisting your project into something you don't care about or use, they can always take your code base and develop their own project upon it. Your original project will still be yours.
Makes sense? At least by sharing it others don't have to reinvent the wheel if your project mostly fits their need.
Adi
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'm drinking beer, but it wasn't free - can anyone tell me what i'm doing wrong ?
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
What I do is follow the plan of least congestion upon the routes of all possible outcomes based on a M/M/1Q. As Occam's Razor tells us, the least stressful path is the most enjoyable one. At least that's what I tend to do. Mostly it's fun, unless Alan is doing something behind my back.
-Linus
Just say No!
:D It makes for good understanding of different views and makes the project that much mo better. Thats what open source is about right?
usually I submit things to a project i am working on that the main developer is not always in favor of. He typically explains why he doesent want to do it, and I typically explain why its a must
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
The concerns expressed here are much the same as those expressed by musicians hesitant about GPLing their recordings. The feeling that the creator needs to maintain ownership is a pervasive one, hard to let go of.
It is better for good ideas to be free. The problem is deciding when exactly to set them free. That's up to you to decide.
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.
The "waste" from forking is more than likely to be recouped from what would ultimately be a better piece of software.
The real world is a special case.
On the big open-source project that I heavily contribute to, there's a system we all go by. Though they all have a choice, the developers give copyright on all source to the project maintainer. In return, the maintainer listens to them when it comes to making decisions. Of course, as the owner of copyright, you have full discretion over what makes it into the main tree. Sometimes patches get declined, and after a little disappointment, you move on. People can always use your patch if they want the feature.
We had a fork of the code happen once. In the end, everybody who was using the fork decided the new features weren't worth it.
In the end, I can't say I've really ever experienced a major conflict where developers left. Everybody who is contributing is doing it because they want to see the software succeed. In turn, you have to be open-minded about contributions. Nobody likes a dictatorial project leader.
um, no.
I really sympathise with your issue and suggest: * The longer I live the more I believe that vision and mission statements are important. * Project management needs to be active. If you can find a group of people who work well together, stick to them and focus on your vision. * I'm sure I'll get it in the shorts for this, but don't release all the code until you are ready. Release enough for people to work with you.
As the previos posters have already mentioned you don't have to merge anything you do not like, it is after all YOUR project.
;)
What I would suggest is that you write a detailed enough TODO list so that others can see your vision. Putting some more of your vision in the README file might be good too. Some wierdos (like me) actually read those files.
And btw, I think you shouldn't listen to those who says that you shouldn't publish until it's done. If you do not publish early you miss alot of the good stuff in the opensource-community. And alot of people (like me) don't want to get involved in huge projects if you let 'em in too late, since it takes alot of effort to get introduced in a project with several thousands lines of code. It's better to be on the train from the startingpoint. (Release often, release early. Always a good practice.)
don't tell others about your project
explain nicely to people why they are idiots and you are not using their patches - just like Linus!
you may accept the comments of people's patches - but edit out the code change suggestions. Then put these editted patches in a file called "stupid_suggestions.txt". This way you will not hurt their feelings.
don't accept any patches from anyone
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.
Don't let the fat linux humping nerds into your project. They are blinded by their shitty OS. Basically anyone who is a registered slashdot user.
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.
Just do what Machiavell- I mean, Theo De Raadt would do.
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
keep it free but closed source until you are where you want it to be, THEN GPL open source it. or just don't release it at all until its done.
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.
What if someone gets angry and decides to fork the project?
If you use the GPL, accept that a fork is possible. If that is not acceptable to you, don't use the GPL. While it doesn't happen to everyone, you could easily have the same fate as David Norman. It hardly takes an angry person.
~~ What's stopping you?
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 don't want to see your 'electric weasel'. Just keep it zipped up and out of sight, please.
You should seriously consider whether your goal might be (gasps!) to make some money off your efforts. You can always GPL later, but you can't un-GPL.
So far, I decided not to GPL my project but I've still received tons of positive feedback, much of which has become incorporated into the code.
If you really value control, and you don't like the thought of your baby being forked or sold without your consent, you ought to at least consider not GPL'ing.
-Scott
Here's what I do: Bitty Browser & Andromeda
Write godawful, fugly code. If you make it hideous and incomprehensible, then NOBODY will ever submit a patch and your problem will be solved. Here is a good starting point.
I just built a web server out of legos. It's shaped like pikachu and it's running Debian 3.0. I had Linus and the Transmeta crew help me with the CPU. It's made entirely of shards from CDs that have been spun too fast. I hacked the kernel so you can watch the Cowboy Bebop movie instead of the boot message. I used a 160GB dual head hard drive that can't be hacked. If anyone needs a hosting provider for an OSS project let me know.
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
I am considering releasing a project that encourages forking... infact every patch or new version will be viewed as a fork.
With my project, I will have my endorsement as founder to give to a tree (or more). I would try to merge trees, and give them their own fork.
We don't have (or possibly have but shouldn't have) control over what other people need. Everybody should have control over their own system, and allow others to benefit from their system enhansements.
Basically, accept everything, (if you hate a patch don't do work to implement it, let somebody else implement it) and endorse only the best.
Your mission plan might change if you see what other people need.
Mission plans are tools, not gods.
Please use [ informative / summarizing ] SUBJECT LINES
Flame me here
Yes, and call it theovon_ass_clown_v1.0
As a devout communist I am offended. I want nothing to do with the felching pedophiles that are behind this ugly wave of OSS. I would rather have my goverment assign software to me as needed at the expense of the state. The only thing worse than these GNU propeller heads are those folks out there that think OS Ten ( there, I pronounced it right ) is the height of computer science. I don't know why everyone likes OS X, it wouldn't install right on my Pentium 4.
this is an empty message, but only looks like its got something in it because of the lame lameness filter.
First off I think you are making a mistake in worrying about unwanted patches and forks. Generally open source projects face a lack of interest, your project is going terrifically if you are generating enough interest to be getting unwanted patches and forks. :-)
l egal-200207/msg00007.html
Anyway here is an open source license (proposed LPPL 1.3 draft) which gives you the control you want. Again I don't recommend going this route but it meets your needs:
See http://lists.debian.org/debian-legal/2002/debian-
Think possitive. Software does not mutate, it evolves.
As you state your mission (goal), you probably have thought about the structure as a whole,
there might be even milestones (like when to do a release) but as software evolves things will
change. again and again.
It is your task , as a project manager, to make descisions. You can decide whether to accept or reject patches. It is here where
it comes down to communication with the developer of that paticular patch that violates your mission in a way it would 'mess up' your structure, don't stop communication,
instead negotiate about how to put it in properly (ask for (visual) explanation).
Have a repository ready for contributors (cvs) , you still have the release-branch.
It sounds in your article that you see the software as proof for your idea (acknowledgement), which is correct, but
the structure of the software might in the end
not correspond with your idea in the first place, but most likely you will be happy that
you have done it, to see the software evolved
into something even greater:)
That'd unfortunately have the opposite intended effect. I'd violate your vision on a daily basis until I got attacked by electric weasels! (I just wanna see the weasels)
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.
"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.
If someone else thinks that they can write a better widget than you can, they are free to try. Either way, we are all better off: more widgets, more choices, more for everyone.
Yes, working with other people can be difficult and frustrating. If you want to maintain complete creative control and prevent others from modifying your work, the GPL may not be for you. If you want to make use of other people's time and tallent, then you have to give up some control or people will call you an overbearing ass. If, however, you reall care more about sharing ideas and getting things done, than about controlling every jot and tiddle of the project, then you can get a great deal out of open source colaboration.So, lighten up. Set your project free as early as possible. Accept help from folk that share your vision, ignore the rest. Try not to be too rude. Don't get hung up over control or competition. Write good code and have some fun doing it.
1. I'd not worry about the GPL fork issue. Even if it happens, who cares. That's the beauty of the GPL. If you were planning on releasing your code to the community (via the GPL or however) anyway, you obviously want others to benefit from your code. And a seperate project shouldn't stop you from fulfilling your goals (presumably the other project forked because of incompatable goals - so no overlap). 2. You might check out Guido van Rossum's approach to maintaining Python [python.org] His style seems to be what you want to do, and I think it's safe to say that python is a sucess (no script-wars flames please).
Cactus?
In the early stages, it is very important to keep control over your creation. However, once it gets going in a particular direction, let it go instead. Patches and features are added by other developers because they found them useful. If they found these additional features useful, someone else will as well. Further, these additional features may build your project into something far grander than you initially imagined. I seem to recall reading an article earlier today containing a usenet post about a new OS Kernal that probably wouldn't handle much more than an AT Hard drive and wouldn't ever really be big.
I have a new open source project I am considering releasing sooner rather than later
Unless you are planning to release Real player's streaming video codecs (see here), I wouldn't worry too much about too many patches and forking.
And drink lot's of beer. It really helps.
IANAL, but imagine a beowulf cluster of in Soviet Russia all your belong are base to us welcoming the new SCO overlords.
Two very useful things in releasing code that has made various projects successful.
First, in the tradition of Dilbert, make a "mission statement" to show the overall direction you want to go with the project and what steps you'll need to take to get there.
The second is to make a "schedual" of the specific tasks and requirements. Example of an email programme:
0.1.0: Initial release to the public
0.2.0: go from just commandline to optional GUI
0.3.0: parse html1
0.4.0: parse html4: limit to purely html
0.5.0: parse more extensive html (css/js) but include permissions for certain actions.
0.6.0: incorporate i18n
0.7.0: include extended MIME capabilities (more filetypes, encryption, md5, pgp etc)
0.8.0: add news protocols
0.9.0: add irc stuff
1.0.0: Clean stablized basic internet utility
Ok, that mutated horribly, and got pretty far in a very short period of time, but you get the idea. This gives people an idea of where to goto.
Additional ideas include making an Architecture and Framework document (a hacking howto, if you will). This way, people that want to develop with the project will no what you intend to do and what you prefer them to stick with.
An additional thought: be willing to let the project be organic; if you're not willing to swing just a li'l bit, you'll get more real hard detractors (whiners) than supporters.
"Yeah...it was the numbers that were irrational, not the murderous cult of vegetarians...." -- Hippasus of Metapontum
Sorry if you got confused.
"Yeah...it was the numbers that were irrational, not the murderous cult of vegetarians...." -- Hippasus of Metapontum
See the Apple Developers License for an idea of why the concept of "it's free for the taking" is incorrect. Eric and Dickie would both smack you for that one.
"Yeah...it was the numbers that were irrational, not the murderous cult of vegetarians...." -- Hippasus of Metapontum
Hey, I was looking for something just like this! Thanks for the tip!
(wget does too much and is not too flexible).
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.
What an incredible combination. You want other people to make what you want, for free, and you're asking how you can best keep them from polluting "your" project.
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've written many free source programs over the years, contributed most via DECUS SIG media to the world, but available to anyone. I would suggest going ahead and releasing what you want. It is quite rare for someone to contribute enough to a project to matter much, and if you are still active with it yourself it is far more rare to have difficulty adding what you like from the other code. If you are still developing it, just take it where you like and let others adapt and adopt what they will. If you are run over by a bus, maybe the code will survive you but if not, you can take it where you will.
If you expect to release something and have hordes of others contributing to it under your orchestration, I suggest you will be disappointed. That happens once in a blue moon, and generally after long exposure of your stuff.
The problem is, if you release the code under some bizarre license, people may look at it and say "nuts" and not look again. If you want, put in your license that people may use, distribute and modify your code but must send you modifications. Good luck getting any, but maybe you will. You can of course state restriction X lasts for 2 or 3 years also. I believe that such legalism is a waste of your effort, but do what makes you feel better, but go ahead and share your work, and under terms so others can share it also.
Glenn Everhart everhart@gce.com
are SPAWN OF SATAN!
Part of the fun of OSS for me is that others will say dumb and smart things. Without some truly useless ideas, the great ideas can't shine. Having contributed patches and bug reports to OSS projects, that's the fun. Flame wars in my mind are useful when they stick to the technical details.
It's a pity I have to comment on it even though it is irrelevant to me. I'm doing it now, and I will regret it in the future.
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
Open source doesn't mean open development team. Interview developers you'd like to work with you. Keep the team small (4-6 perhaps). IMHO, if you release it to the mob, you really don't have any control over it, nor should you (as it becomes more a property of the community). Of course, you could go the Linus route: come up with something so revolutionary (or in the right place at the right time, or whatever the case may be) that people are convinced that they have no choice but to bow to your will. :-)
The best thing about a boolean is even if you are wrong, you are only off by a bit.
With the personal head start you have on the program it might help you to maintain your focus and help evangelize to others what your goals are because you've already invested some time and energy in the project.
Height: 38U, Weight: 0 Newtons, Eyes: #0000FF, OS: Gray Matter 1.0 (Alpha)
Just wait until you get an email from someone who is going to start selling support for your product to his customers.
Is it legal under the GPL? Yes.
Do you feel used becuase someone is making money off of your hard work? Yes.
Will they actually make money? Hell No! My developers and users already provide kick-ass support for free. Why would someone pay this guy's dumb ass when he probably doesn't even understand the source code.
ÕÕ
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.
Yes, this is supposed to be funny. Laugh. Moderate with "Funny". Thank you.
(And moderate this post up to informative.)
Why bother.
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.
Check out the MPlayer development mailing list. It shows how a opensource project should be handled, with things like a strict patch submission policy to the lead developer's wrath (Arpi).
Ok, I am not a programmer. I am in the IT field, but that really doesn't even matter. I mean this kindly, but your question is the fodder for a Dilbert cartoon.
Look at it as a question of something you might do at work. If you make a good suggestion at work for a way to improve a specific area, then that idea gets kicked around, talked up (or down) and gains it's own momentum.
The reason for this is that, once the idea is posited, it becomes sort of a "group objective". You may be asked to run with the idea alone, or to collect input and present a possible solution based on that, but in the end, your idea is an idea to improve your companies business. In other words, you may get a bonus, a good performance review, or at least an "Atta-boy". But you never really question the recognition in the end. That was never the point.
Why? Because you are a part of the team the solution was meant to WORK for. Someone in your company could steal your idea and claim it for themselves, but at least you have people around you that KNOW it was your idea to begin with, and that helps a bit, because in business you expect these things to happen.
In a truly broad-based, decentralized organization (such as the open source community), the possibility of someone running off with your idea outright, or re-doing it to make it more appealing without your input, is much greater. And you don't even have that supportive group of people around who will be able to say, and rightfully so, "Dude, you got SCREWED!"
In the "at work" scenario, you got recognition, either monetarily or otherwise, because you were known in that group. Now, you are wading into the great unkown. How does that work?
The same way. You are still part of a group working for the best solutions. Money probably won't enter into it, but recognition might. And if you get asked to kick it around for input to come up with the best solution, even though in the end it wasn't exactly what you started out looking for, the process is the same. The rewards are the samr to. Your contribution, your efforts, work to make the whole greater.
So thicken up your skin, set a few guidelines for what is and isn't acceptable for your version, and if somebody builds a better mouse-trap based on work you started, in the end, well, you know how it all happened. It started with you.
Christ, should we sing Kumbaya here?
Best of Luck!
But watch out for the nuts out there, and don't give in to them. On one project I had on SourceForge I got into a real pissing match with some guy who insisted on massively rewriting my source code to match his style of organizing a program's internals. I refused to use his mega-patches several times, and eventually he gave up and went away.
The Artistic license is considered an Open Source License, but seems to allow the author greater control over forking.
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.
If you want Open Source politics, you might want to look at organizations like the
Apache (www.apache.org/foundation),
Gnome (foundation.gnome.org), and
Python (www.python.org/psf) Foundations.
I worked on the Jabber Software Foundation
(http://www.jabber.org/jsf.html) for a while. We developed special interest groups and and an enhancement proposal system based on similar things at Gnome and Python. There is a Jabber Council for which elections are currently underway that form a main decision-making body for Jabber. I put together a piece based on my experience advocating establishing an Open Corporation for your efforts. Still, benevelent dicatorship still has a lot to be said for it, though.
10 January 1610
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));
Excellent suggestions but I think one thing needs to be said:
While it's true people may want to take your project in places you don't want to go, it's also possible they will want to take it in places you never thought of. My guess is there are *many* preojects that we use every day that do stuff the originator never thought of, wanted, or thought possible. Unfortunatly, I have no examples - it just seems right to me.
So, try and be open. It sounds corny, but synergy does happen and great stuff comes from it.
Just my 2 cents...
Personally its not God I dislike, its his fan club I cant stand (bash.org)
Along the license lines; There are, of course, a variety of licenses available to choose from, if you so desire. I've been toying with the concept of some type of "retrograde" license, where the code would be release as open source after a certain date. E.g.: prior to the date of MM/DD/YYYY, the code of this project is licensed under XYZ license. If this date has been reached and or passed, this section of the retrograde licence may be omitted. Upon the date of MM/DD/YYYY and afterwards, the code for this project is provided under the GNU/... etc license. This, essentially would provide me with some time, (as specified by the date of conversion ot OpenSourcing), for me to do with the code things I wish to do. For instance, if I thought the code/project was good enough, I could make a go of selling it, though people could opt to wait to get it for free after the date that it became open-sourced... Just one idea I've been kicking around, feedback is welcome, please keep flames on "Low" :-)
Another (better, in my opinion) idea I've had recently: A platform specific license, specifying that the software is free and open-sourced for use on Linux systems, but reasonably priced and closed source for Windows(tm) systems.
-Note I've not really considered which way to go with 'Mac'-systems.
-Also note, as for Win/Linux dual or multi booting
systems, the licence applies to whichever OS the code is being run within.
Hope some of this may be useful. Thanks to all offering constructive feedback/criticisms.
by the by, I've not really researched the various
licensing schemes available, so if these ideas aren't really that novel, then please forgive my ignorance.
-S-
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.
on my Pentium 4.
What do you mean, your Pentium 4, Comrade? Surely you are not advocating the private ownership of a material good?! You will be sent to the gulag, 25 years!
Oh no, wait, thats Stalinism.
of how to solve problems with people who want to implement parts into your program you don't want can be found here. It's a game for the Palm, and the coder added a large FAQ section where every feature that has been asked for / suggested is discribed, along with a text why he didn't add it (yet). this way, people who suggest something to your program don't get all mad-n-stuff(tm) if you decline one of their ideas.
Karma
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.
Flamebait?
Linus does do whatever he wants, and I reckon that's why it works. People are happy for him to do so.
Announce up front that you want the project to go a certain way. Slap a link to this discussion on the project home page if you like, then be as totalitarian as you need to get the project finished the way you want it.
It's *your* project. The beauty of Open Source Development is that if people don't like it, it's not your problem. They can do what they like with it on their own homepage and in their own time.
Just tell them to fork off.
Powered by onion juice.
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
... or in the words of old timers in the last row: "We Like Roy"
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.
I've seen the same thing from both home and work. I'm running 98 at home and XP Pro at work, but both on a fully patched IE6. Maybe it's the browser; so much doesn't work in it that I wouldn't be surprised... Ah, well, thanks for the reply anyway.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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.
and release it under the GPL, people can fork it
The other obvious drawback is that you will have no income. You don't still live the FSF illusion of the non-existent service&support business model, right?
First of all: When people suggest something that is against your "mission", what's wrong with that? If poeple prefer other solutions, than it usally means that these solutions are better to them; they result in a more useful program for the public. And that's what free software is all about after all, isn't it?
Others have mentioned it already: First try to examine whether it's not actually best to reconsider your "mission"...
When being open and accepting contributions that deviate from your ideas, you may loose some influence on the direction your project takes. When denying contributions, your project may get forked and loose its uniqueness. We can't tell you which way to go; it's up to you to decide which is your priority.
However, don't be scared of forks too much. They are quite seldom, and only if the project already *has* gotten some popularity.
If it actually happens, that shouldn't bother you too much. Maybe the fork gets a direction so unlike to yours that it can't be really considered competition. In any case, it doesn't hinder you to go on and head for your own goals.
And if your "mission" turns out to be a better way to go at last, people will stick to it, or return. A fork can only overtake you if it actually turns out to have the better vision in the long run...
All my comments get moderated +-0, spotless.
He who controls CVS controls the source. Ususaly somone will demonstrate that they adhear to your vision by the patches they send in. Then, to aliviate the workload you can give them CVS access. If they deviate too much you can revoke it (though this is rarely done). If people feel you are not taking it in the direction they want they can simply take the code and set up under a different project name. They get what they want, and you keep a tree that adhears to your vision. Of course it is always best not to fork a project and being flexable will sometimes get you to where you want to be faster than if you were not.
If others don't like the direction you're taking, they will fork the project and patch their own.
You are worried over nothing. That's the way open source is supposed to work.
The thing about things we don't know is we often don't know we don't know them.
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