Open Source Politics - Maintaining Your Vision? 181
"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."
It may be too simple. (Score:4, Insightful)
.
Re:It may be too simple. (Score:1)
I think this is a good compromise. But the one time I tried it, I got accused of not truly following open source ideals. Go figure. Anyway, I ended up just releasing what I had as a series of release candidates, which worked fine for my small-time project.
Re:It may be too simple. (Score:3, Interesting)
Too many cooks can spoil the broth, but as the 'broth' becomes more mature it can handle more cooks.
I would think that a good way to avoid the contamination of 'unwanted ideas' would be to clearly lay out the first few releases. "Release one will have... blah blah, Release two will have blah blah. After which Release three is open for suggestions."
On top of that, use your 'planning documentation' to direct the project. Lay out how you wish contributions to be coded, etc. Demand good documentation of contributed code, as it's easier to implement things when you have that 'map' of what's being done with the code. (verify that the code does do what the comments say it does!)
Just because it's open source doesn't mean that it can't be structured. In fact, open source is more likely to be structured because of the many contributors and wide ranging talents. A well-structured project is more likely to survive than a poorly structured one because it will be more appealing to more developers.
-Sara
Re:It may be too simple. (Score:1, Funny)
It is yours (Score:4, Insightful)
Re:It is yours (Score:2)
Once you have released the source code under an open license, such as the GPL, the source becomes ours(*) but the project is still yours.
If someone submits a patch that strays from your mission, or you don't understand, or uses the wrong bracing style, you don't have to accept it. It's your project after all, and if they don't like it, they can fork themselves!
So some upstart has forked a new project with different aims from yours, but based on the same original codebase. Big deal!
In fact, congratulations! Your code is useful to someone other than yourself. It feels good doesn't it?
If the project is uninteresting, or has ideals and aims that are widely disagreed with, it'll get precious few coders onboard, and as such, it probably deserves to fade away. If not, it'll quite likely get a decent following and will thrive. Such is natural selection.
Those are simply the risks and responsibilities that go along with the benefits of releasing your code to the community.
* Yeah, I know... all work is automatically copyrighted by the Author(s), but I'm trying to make a point. Allow me a little linguistic leeway here, okay?
Define your goals (Score:5, Informative)
As for things you don't understand or things that you don't think would fit, ask the submitter why they think it should go in there, and basically demand an answer better than "Because I like it". If they can convince you that it's a Good Thing, then look into including it. If not, then there's nothing wrong with disagreeing.
And just because someone forks the code to get their features included doesn't mean they can't be merged later. If your software has a clear and concise plan, people will generally choose that over another project slapped together because the project admin didn't like their idea. Yours shows thought and planning, and as I said before if you decide later that the previous idea is a good one, you can always add it later.
Re:Define your goals (Score:5, Informative)
This is probably not the case. If the forked version has feature X that most people want, and yours doesn't, they'll take the fork. If the fork has www.programfork.com and you are member.isp.com/~you/program.html, people will find the fork. If the fork has a higher listing on google, people will find the fork. If Microsoft makes a fork and includes it in windows, people will use the fork. (Not to bash Microsoft, but people will often fork a program and include it with their own, and Microsoft is a common example.)
Re:Define your goals (Score:1)
Re:Define your goals (Score:2, Insightful)
Never be so rigid as to refuse any change in the design document whatsoever, though. If many people are wanting a feature, or want to take things in a different direction, then you have the choice to incorperate that into your project, or sit by and watch them fork it.
Managing projects is always tricky and there just aren't rigid rules that every project should follow. Well, maybe this one rule.. always try to be rational and logical about things rather than emotional. It sounds a lot easier than it actually is -- programmers get attached to their code and their ideas, and it can be hard to influence them to change when they make up their minds. If you try to approach things with as little bias as possible (while keeping your goals in mind), I think you'll do well in most any project.
-Sou|cuttr
Re:Define your goals (Score:2)
Another good practice to prevent forks with (really) large programs is to make it very modular (use libraries etc) to enable other developers to develop their module which will be usable even if you don't want their stuff in the main program. An example would be a music-player with a Gnome GUI. If you'd design it modular enough, another developer can develop a KDE GUI without touching the core program while otherwise they'd probably have to fork.
Re:Define your goals (Score:2, Informative)
I would concur with that advice. Most people who submit patches understand how the Open Source model works, and they're usually not under the false impression that project admins have to incorporate all submissions. Also, if you explain why a particular patch or suggestion isn't going to be incorporated, the person submitting the patch/suggestion is less likely to take offence.
With my project (see shameless plug below), I was fortunate enough to have a fairly large company "sponsor" a feature for me. The difficult part, though, was to try and not be influenced by the "sponsor" too much. Even if you receive corporate backing of one sort or another, it's important to draw the line somewhere, and make sure they understand that they haven't bought you or your project. (In my case, the person I worked with on the other side clearly understood where we stood, so it was hardly ever a real concern.)
Another thing to remember is that people simply may not care enough to bother forking. I don't mean to be demeaning, but just want to point out the statistics. The fact of it is, most "Open Source" projects are written and maintained by a handful of people, with a slightly larger group of people testing (real testing, that is) and submitting patches. Although it may depend on the type of software, typical users aren't going to submit very many patches, or even feedback in general. For most projects, I'd say it's more likely for people to just stick with the project than to go through all the trouble of forking. But if they do fork, that's also not a bad thing (afterall, we're for competition aren't we?)
Start with Humility (Score:5, Insightful)
Of course, this is assuming your project will be interesting enough to attract smart people.
Re:Start with Humility (Score:4, Insightful)
I'm convinced (now) that had I held true to my original vision, it would not have turned out nearly as well as the team's vision did.
Re:Start with Humility (Score:2)
Don't publish until you're ready (Score:2)
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)
State your goals. (Score:5, Insightful)
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)
Just be clear (Score:1)
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.
Its simple (Score:2, Funny)
Along those lines I may have to release a GPL version of my electric weasel.
Re:Its simple (Score:1)
I'm not too sure what purpose I would have for an electronic weasel, but if it can be made to attack people, especially in real life, I think I'm going to need three or four. :P
IMO (Score:2, Insightful)
Blah blah blah (stupud subject for a stupid post.) (Score:1, Flamebait)
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. (Score:1)
It's your project (Score:1, Informative)
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
Keep control of the project as it's founder. (Score:5, Insightful)
If you end up with a lot of developers working on the issue, I would suggest that they submit their plans for enhancements, corrections, etc and that you and the other developers discuss it and agree upon a schedule.
In case of disagreement between the devleopers, you have basically 3 ways of handling it:
1. Ignore it (not very good)
2. Excersise founder rights and decide what to include (Linus style?)
3. Have the suggestor implement it in a branch, test it out and discuss it. (Better, as it will demonstrate its usability and functionality to you)
Having a mailing-list for developers to discuss issues like this is also a good idea!
In any case, good luck with your projects!
build to satisfy your needs not to compete (Score:5, Insightful)
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.
Yeah, Forking is GOOD (Score:1)
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.
But merging can be BAD (Score:2)
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?]
Re:But merging can be BAD [reply to OT request] (Score:2)
Re:But merging can be BAD [reply to OT request] (Score:2)
Maybe it's some newfangled HTML copy protection
Be strong (Score:4, Interesting)
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.
Re:Be strong (Score:1)
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.
Definately agreed upon this point. Too many times you can see projects listed on Freshmeat that have descriptions which promise the earth - you download them and discover there's no code.
That's worse than seeing posts on the SourceForge saying 'I'm looking for volunteers to write the successor to $foo - BTW what's C?'
I've found that the best thing to do is make sure that your original release is as functional as possible. Otherwise people will not have a good experience with it - to the point of refusing to try it again in the future 'Oh, I tried that before - it sucked'.
Open Source != Open Project (Score:3, Informative)
In order to maintain control of your project, simply limit the number of committers to the repository to a select few you trust (or just yourself.) This approach has worked extremely well for the kernel source.
If someone is hell-bent on introducing something you disagree with, they have the option of forking the source and creating their own project, but this seems to be the exception and not the rule.
Couple Things... (Score:3, Interesting)
-- Robert
please excuse speling and gramar
Re:Couple Things... (Score:1)
Re:Couple Things... (Score:1)
I'd like to add that this improves the quality of the developers which join your main fork. With less people working under a different vision on the other fork, you'll get more people with a vision similar to yours working on your project. Essentially what would seem like trash to you, but isn't with the other fork, is conveniently routed their way. It also makes feedback easy to handle, you merely say "You might be interested in the work of 'x' project..."
Benevolent Dictator (Score:3, Informative)
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 [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 [buildinglinuxvpns.net]
interest (Score:5, Informative)
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 [tuxedo.org] 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? [gnu.org]
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.
Re:interest (Score:2)
This article really does show the attitude RMS has towards everyone else. His aims aren't to make life easy for developers, it's to make life as hard as possible for people who don't want to choose GPL:
And that's the bottom line. GPL may give users freedom, but it's certainly restrictive for other developers. If you really want your code to be free, and let people do what they want with it, (though remember that includes selling it) choose something like the new BSD licence or X11 licence.
Re:interest (Score:2)
Re:interest (Score:2)
They're unreasonable to me. Not as in me wanting to deny you the right to use whatever license you want. However, consider this:
Personally, I code because I enjoy coding.
If I release something and expect no financial gain for it, I release it as truly free software, without any strings attached.
If I want to gain financially, I don't release it for free (or more usually, I do the work for an employer, who usually demands it's kept in-house).
If I write free stuff, I expect you to do so to if you use my work.
That's your choice, and if so GPL's good for you. But, how does restricting how the things you've given away for free are used help you?
I personally, haven't found it helps me, so I don't use the GPL to release my stuff.
However, as the GPL is so restrictive, I'd urge people considering how to licence something to think carefully before they do so. GPL is like a virus. If you release something as GPL for a while and people add stuff to it, you can't even release your own project as truly free software (such as BSD) without removing all other contributions or contacting all contributors (hard if they are anonymous or addresses no longer work, etc). In fact, in 6 months time, are you even going to remember exactly who provided a 1 line patch?
Maybe a GPL like licence that gives the original author the right to additionally relicense the software and any other derivative works under any licence would be good. But that only protects the original author, not any major contributors down the line. I think the only truly fair way is to say, "Do what the hell you like with this."
Re:interest (Score:2)
You clearly haven't understood what I've written. My argument is precisely that all developers should be able to beneift from my code if they want to.
GPL is designed to restrict who can benefit from what you're releasing. BSD doesn't.
Re:interest (Score:2)
GPL is designed to restrict who can benefit from what you're releasing. BSD doesn't.
The GPL does not actually restrict anyone benefitting from what you are releasing. Microsoft could use GPL'd code if they wanted to.
What the GPL does is to stop developers who like to take that code so nicely put there to help them do what they have to, and then decide that they do not want to let any other developers benefit from the code they wrote. The GPL is a way of saying "my house is your house, but only to people prepared to do the same for me (it doesn't matter if you live in a tent or a mansion)".
That's why some companies call the GPL a virus : because all they want to do is freeload off of the community. As a quick question : I'm sure Microsoft has said that they think the BSD license is great... so what products exactly have they released themselves licensed under it?
But if you are willing for absolutely anyone to use your code for any purpose and don't expect them to give you anything in return, go ahead and use the BSD license.
Re:interest (Score:2)
The BSD license ensures that the users of the software have complete access to the source code and the ability to modify it.
Many feel that guaranteeing access to the derrivative works is important. Some, of course do not.
My argument is precisely that all developers should be able to beneift from my code if they want to.
The BSD licence does not guarantee this, since it permits the creation of derrivative works that could be propiratary and thus those derrivative works are not availablel to any developers.
I guess it comes down to what is meant by "beneift". If you mean "sell proprietary versions of" then of course the BSD lisence is a good choice. If you mean "be able to access subsequent work", then this is clearly not served by the BSD lisence.
that's easy (Score:2)
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.
My humble thoughts (Score:2)
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.
say No (Score:1)
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
Whoa, cowboy! (Score:5, Insightful)
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.
Be Like Linus (Score:2, Interesting)
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
Open Source Music (Score:1)
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.
keep an hand on the reins (Score:2)
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.
U da Boss (Score:1)
The "waste" from forking is more than likely to be recouped from what would ultimately be a better piece of software.
politics (Score:1)
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.
Patches (Score:2)
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.
Grow some balls (Score:3, Insightful)
Step 1 is get over the attitude that you need to keep everyone happy. It's your project, run it the way you want to. It doesn't mean you have to be impolite, but just preface every e-mail with "thank you for your interest and submission, but..."
If someone's code isn't good enough, send them a message that says, "I'm sorry, but that patch doesn't follow the style that I'm trying to enforce for the code."
If the patch takes it in the wrong direction, say so. If you don't understand the patch, then chances are it wasn't documented well enough. Say "I'm sorry, but your patch isn't documented well enough for me to understand. I only have so much time to look at patches.
There's no reason you have to accept everyone's contribution. And if someone decides to fork the project, so what? If it's better, then maybe they're doing you a favor and you can use it (and perhaps fork it back in the future). If not, keep plugging away at yours, since presumably it's something that you want.
But the bottom line is to write code that pleases yourself, and don't worry about pleasing others. To be honest, I have a feeling that this question is really, "How do I get people in the community to like me so that they'll see me as one of the 3l33t?"
Maybe no-one else will be interested (Score:2, Insightful)
I think that maybe your primary concern should be how to get other people to be interested.
Maybe the GPL isn't for you (Score:4, Insightful)
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.
Follow the masters... (Score:1)
idea (Score:1)
Open Source punditry vs Control (Score:3, Insightful)
Fork, Fork, Fork. (Score:1)
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 [atthat.com]. It hardly takes an angry person.
Complete modularity (Score:2)
Re:Complete modularity (Score:2)
Modularity generally works best if you have simple interfaces but complex implementation. If it is the other way around (or complex both), then modularity is tough as nails.
Strong Leadership is Key (Score:2)
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
always give rapid feedback (Score:3, Insightful)
I had a GPL'd project that was fortunate enough to attract the contributions of a small handful of generous people a while back. In one case I handled the contributions well, and everyone was happy. In another case, I did not handle it well at all, and I feel bad about it to this day. Here's what I did; perhaps my story will help you out:
The project was so closely intertwined with my real-life job that I found myself leaving it untouched for long periods of time as work dragged me in other directions.
One patch I got was a clear win. It came during a period in which I had time to integrate it quickly, so I did, and made a new release. This was a good case - it made me feel happy and I hope it made the contributor happy, too.
However, there was another case where the patch wasn't so clear a win. I thought I could implement a better solution, so I didn't integrate it. Then, I got dragged away from the project for a very long time.
I never wrote back to the contributor - I didn't want to create bad feelings by criticizing his solution, so I took the easy way out. (Mistake.) Ages later, I announced that I was stopping work on the project because I was changing jobs. The contributor was pretty upset that I hadn't used his patch in all that time.
So, my advice is, if you're given a patch that you don't want to use, don't use it. Tell the contributor what's wrong with it right away. Saying 'no' to someone may be hard, but leaving them hanging is worse.
Look on the good side, if your criticism is constructive, perhaps they'll fix their patch so you can use it.
- Tim
As much as they don't want to hear it... (Score:3, Insightful)
It shouldn't be hard to modify an existing LA to meet your needs. If your project is useful, they will still come.
-Sean
Re:As much as they don't want to hear it... (Score:2)
And now for something completely different... (Score:1)
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 [turnstyle.com] 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
Re:And now for something completely different... (Score:2)
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.
fugly (Score:1, Funny)
My opinion (Score:2)
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
LaTeX license (Score:1)
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-
Lay low until your project takes form (Score:1, Insightful)
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.
Well... (Score:2)
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.
what's the problem? (Score:1)
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.
Benevolent Dictator approach. (Score:1)
What's cookin? (Score:1)
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 [slashdot.org]), I wouldn't worry too much about too many patches and forking.
And drink lot's of beer. It really helps.
PHB! (Score:1)
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.
Suggestions (Score:2, Interesting)
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.
Be a civilized bastard. (Score:5, Insightful)
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.
not really hard.. (Score:2)
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...
From My Experience (Score:5, Insightful)
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.
OR Re:From My Experience (Score:2)
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
Re:From My Experience (Score:2)
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.
I subscribe to the view that, from any one persons perspective, most people are idiots and that even the people that are not normally idiots, are idiots a significant percentage of the time. I include myself in that, so it's entirely possible I'm being an idiot right now, but I suspect it's just a subjective matter of perspective. It's just occured to me their could be perspective distortion which could *make* people appear to be idiots even if they are not, but that's off topic and it complicates things for me so I'm going to ignore that.
Anyway, IMO - unless it's obviously a good idea, or unless the someone points out a good reason why it's a good idea then the idea should be ignored, because there is an overwhelming chance that they are idiots and their idea is idiotic.
I think constantly adding features and/or constantly questioning your goals can lead to bloat, unwarrented forking, delays and feeping creaturism.
If it's a good idea but not what you had in mind then forking would be a good thing, and you might want to plolitely suggest that (and offer to link to it, as a peace offering to demonstrate your not just being an asshole).
So I'm not disagreeing with you much, but I do think people deserve more contempt at their stupidity.
I know a number of lunatics that like to add patches for things that nobody but them wants, and then get all stroppy when they don't get applied, and as a result have always thought it better to ask if it was wanted or even already being worked on before creating a patch (unless it's for you in which case you are unlikely to care and can always make the patch avalible on your web site).
Trouble with vision? (Score:2)
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!
My pessimistic viewpoint... (Score:2)
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.
Experience in a nutshell... (Score:2)
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.
Control inversely proportional to contributions (Score:2)
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
Code for Fun (Score:2)
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.
Just look at Xemacs (Score:2, Informative)
Want to know what happens projects fork due to politics?
XEmacs Vs GNU Emacs [xemacs.org]
In particular I find Richard Stallman's point of view quite enlightening on the GNU System and FSF.
PHPLIB experience (Score:2)
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.
The Myth of Open Source... (Score:2, Interesting)
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.
Wishful thinking (Score:3, Insightful)
Actually, what you should do when someone requests a change or submits a patch, accept it and be grateful that someone spent time trying to improve your code.
One of the purposes of open source development is to encorage participation so that many different ideas can be tried.
Remember, Linux started as a terminal emulation program...
Why do you want to open source it? (Score:3, Interesting)
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.
The answers I came up with... (Score:2)
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 [gangplank.org] 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...
Re:drinking (Score:1)
That's simple - you're leaving the store through the checkout lines.
Re:How typical. (Score:1, Insightful)
Re:How typical. (Score:2, Interesting)
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...
Re:How typical. (Score:1)
Mod parent up.
Re:How typical. (Score:2)
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.