Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
How to successfully implement democratic (non-BDFL controlled) type of management for the open source project?
More specifically - for the project using distributed source repositories.
What style of communication is best to adopt in such environment?
How to encourage merging branches into the master?
I am mostly interested in establishing the situation where people can directly merge into the master branch under the "social contract" agreement that they follow the project roadmap (which they themselves help to define) and that code they commit is tested.
I specifically want to encourage workflow
define the problem->define requirements and specific metrics of success->architect->build and test
The reason is that - I often see emails like here is the problem and here is how I think it should be solved
Immediately somebody else jumps in and starts a fight.
Not productive at all.
Often disagreement of that kind stems from not being on the same page on the problem definition, requirements or architecture. Or sometimes just because nobody even thought about such things.
How to encourage people to analyze the problem properly, share great ideas and select the best solutions?
How to organize communication so to avoid silly fights, make good decisions without being overly bureaucratic and move along at a good pace ?
Would you have any suggestions? Are there examples of projects managed this way?
How do you think adoption of distributed revision control instead of centralized affects the style of project management?
edit: found some interesting links in related questions
http://gettingreal.37signals.com/toc.php
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/
Sorry for this somewhat off-topic answer (i.e. one not addressing directly the question). Please edit at your heart's delight!
Projects _do_ need executive governance!
Such may come from a single Benevolent (or not) Dictator, or a [IMHO, small] group, possibly open, of diverse but like-minded individuals. A standard joke on this is that: "The group should be made of an odd number of members, and 3 is already too many"; in truth, small collegial committees can be very effective.
This requirement for a "non fully democratic" decision making entity is however somewhat aligned with the processes suggested in the question. To effectively harness the good will of contributors to the project, the executive team needs to
be perceived as legitimate
communicate effectively
empower "the masses" to contribute with roadmap definition, problem identification, solution scoping and all other design-level tasks. (All the while it remaining clear that in the end, and after all has been said, final decision will be done in committee.
DELIVER a good and vibrant product (BTW by adopting agile development processes, the time between deliveries is lessened)
compromise when needed
advocate the interest of pooling resources in a coordinated fashion, rather than branching out.
Share the glory!
To support all of this formal documentation and processes are very useful. For example, the define the problem->define requirements and specific metrics of success->architect->build procedure indicated in the question can be implemented in the form a single collaboratively edited document (wiki-based or other), i.e. one per issue/idea. This document is templated with a defined format: required attributes such as date, initial posting info... and sections which are opened (and closed) for editing following a given schedule. This allows keeping a clean(er) record of the way the collective though of a given issue, what was suggested etc, what was [authoritatively] decided and why.
With such a process, the community feels engaged and hopefully individuals not too disappointed when the eventual decisions do not go "their" way. They can read and comment on the what and why of the decisions.
Another useful approach is to reward effective participation by informally (or factually) provide more weight to the contributors who effectively help with the project. The more active members can either gain their way into the "inner circle" or be handed-out leadership roles on subsets of the project.
Finally, the leaders of a project (whether in the context of a "democratic" or of a "partially dicatorial" leadership) need to be ever vigilant about "peace keeping". Contributors to Open Source projects are typically energetic, smart and opinionated individuals; conflict of opinion, conflict of personalities, impatience etc. is to be expected. These clashes however can be eased by systematically addressing issues with clear facts, moderating/editing aggressively against name calling and non-productive forms etc.
Originally posted on MetaOptimize.
Constitution for Governance of Open-Source Projects (v20100227)
Let it be affirmed that the primary goal in instituting governance of an open-source project be to ensure the long-term health of the project.
Accordingly, the default bias should be towards openness and inclusiveness.
However, policy should be changed as issues present themselves, in order to maintain the long-term health of the project.
For the model of decision making, we favor a "do-ocracy".
The people who contribute the most generally command the respect of the community.
Alienating them is the best way to derail the project.
The repository should be open the committers, given that commits can easily be reverted and commit-access easily revoked. This is preferable to alienating potential committers.
To ensure transparency for developers new and old, and allow them to decide their involvement in a project based upon the history of the project, their should be transparency and openess in the inner working of the project. For example, the email archive should be public.
Lastly, let us remember that too much red-tape gets in the way of progress. So red-tape and other barriers to contribution should be avoided, and only added as issues present themselves.
This Constitution can and should be amended as issues present themselves.
Therefore be it resolved.
access to repository
there are several options ranging from one controlling committer to anyone can commit - but upon social agreement that they respect the project guidelines and the roadmap.
in my opinion distributed repository allows you to be more relaxed with who you allow to commit, because there are multiple backups and the repo becomes virtually unbreakable.
on a separate note - anyone can commit approach - which I would like to test out - sounds more like a "wiki". I can directly compare this with my experience managing a wiki (nmrwiki.org): where despite complete openness - where not even user registration is required to edit the resource, people are often wary about "breaking stuff" and this worry becomes a mental barrier to making a contribution. So a permissive approach to repository management may just work.
Communication style:
email and mailing lists:
discuss everything concerning the project in public (?)
when asking questions - do not bundle
questions with your own opinions
encourage people to propose more than one solution
ask people to weigh pros and cons
be brief and to the point
avoid frivolous language that can be perceived negatively with people that do not know you well
I need to find a technical reviewer for a programming document.
I have looked on Craigslist and various freelancers' websites (RentACoder, Odesk, Elance, etc) but it's difficult to determine who is qualified to act as a reviewer.
The last thing I need is to have the document reviewed by someone who either doesn't know what they are talking about or is not willing to go to the trouble of reviewing the document thoroughly.
An ineffective review might be worse than no review at all since it might generate a false sense of completion.
Any tips on selecting someone qualified & reliable?
The easiest way to determine if someone is qualified as a reviewer is to have them show you they can do the job:
Ask for a portfolio of previous
work, or
(better) Give them a sample
of your current project and ask them
to do a review.
Another option is to ask your contacts for any recommendations.
I strongly advise against relying on a dead-tree (CV/Resume) for making a determination, as it will distract you from weeding out those who "have experience" but cannot do the job, or you can miss finding those who can do the job, but lack the experience.
You could look on SO and see if you can find some people that give answers that give you an idea that they know what they are talking about, though this could be a slow process.
I actually like BryanH's second response, let them review something non-critical and see how they do, but have an idea what it important to you.
Are you looking for someone to be able to make decisions as to what you wrote is technically valid, or do you want someone that can also check the writing and see that the grammar is correct, for example?
There are several things to look at when reviewing a document, you should be very specific about what you are looking for.
Linkedin
Linkedin is a popular network for pitching contracts to documentation freelancers. It's also a fantastic way to procure interest from full-time technical writers at large organisations that might be looking for side-projects (if allowed), or case study projects to leverage their existing skills on new methods.
Mailing Lists
Depending on your geographical location, there are also popular mailing lists with a high volume of contract communications (and passionate technical writers). In Australia, the ATW mailing list is a good resource.
Industry Bodies
If you're in the US, contact the Society for Technical Communication. Other nations will have other bodies (or regional chapters).
Summary
I focus more on the question of "where to find writers" than I do of "how to get a competent peer review", but the right person is always the biggest hurdle. In this way I admit to having a bias in preference for communities of active and engaged participants over something like a bidding website or outsourcing mechanism. The latter is fine, but these islands of technical writers are vocal and active because they are interested, and often give back to the community that makes it available to connect talent to projects such as yours. Good luck!
Have you tried asking a publisher? (O'Reilly, Manning etc)
Obviously publishers need to find technical reviewers and indeed peer reviewers for a number of topics, so they may well be able to put you in touch with someone. They'll probably suggest that you write a book for them, too.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
Question
If you have what you think is a great idea, how do you make your idea open source and ensure that it stays that way? How do you prevent your ideas from getting stolen and patented by someone else?
Background
I recently had an idea about a programming project that I think could be revolutionary. Being a young programmer I realize that I am going to need a lot of help to make this idea come to fruition. I also realize that there are some people who might try to steal the idea and copyright it. I don't know the steps I need to take to make sure that the idea stays open source and how to protect myself from getting the idea stolen. I don't mind if a company decides to make money off of the idea but I do want to prevent one person or company having complete control over it. I have done some searching on the web but haven't found a resource yet that answers my question so I ask you for your help. Any help is greatly appreciated.
Clarification
I'm not looking to make money from
the idea.
I didn't understand the difference
between copyright & patent but now
understand I should have asked the
question using patent instead of
copyright. (question changed)
My goal is to prevent one person or
company from locking up the idea. I
would love to have many people and
companies catch onto the vision of
the idea and run with it. (I can't
imagine what today would be like if
only one company had the rights to
produce engines, electricity, cell
phones, computers... I think you get
the idea :D
I've been down this road myself, and trust me: you can end up wasting a phenomenal amount of time, energy and money trying to protect your idea. Software patents are incredibly expensive and nearly valueless, unless you want to get in the business of suing people all the time. In any event, ideas (especially the "revolutionary" kind) are cheap; there are far more good ideas floating around than there are capable, effective programmers who can bring these ideas into reality.
If your idea is good and you prove yourself capable of executing it, you'll do fine. You're better off putting your effort into that.
As a young programmer, the greatest danger is not that someone will steal your idea. It's that no one will care about your idea. Your biggest goal ought to be to get your ideas and code -- and especially your name -- out there to get people's attention. (Not in an obnoxious way; by doing something worthy of respect.)
One of the ideas behind open source is to make it more attractive for people to work with your existing project than to "steal" it and go off on their own with a fork. Forks are a pain in the ass because you either have to keep merging in changes from the original code, or you ignore the original project and lose out on the work being done there. So it's to everyone's advantage to stay together. You want to keep it that way, as the owner of the project.
Ideally, your technology becomes popular, and as the owner/founder of the project you acquire a reputation, and a deserved position as the Big Expert on it, which will become quite valuable to you. Good luck.
I'm sure you have a great idea, but believe me when I say that a great idea is only a very small beginning. "Stealing" the idea means someone else has to invest the time and effort to take it to market. You still have to put that time and effort in too. If the system allowed everyone to claim ideas and prevent other people from implementing those ideas, we'd be in worse trouble than we're already in.
With the case of copyrights, you have to actually write something (a book, code, etc.) and you automatically own the copyright. The trick is to be able to prove when you wrote it. One easy way is to print it all out and mail it to yourself in a sealed envelope. Don't open it when you get it back. The postmark is a decent proof.
With the case of patents, you can't actually patent an idea without a design. You still have to put a lot of effort into figuring out how it's going to work.
Your best bet, if you really want to keep it a secret, is to not tell anyone. Then, stock up on ramen noodles, pizza, and diet soda, lock yourself in a room for 6 months, and build it. The chance that someone else can "steal" your idea if you do that is relatively slim. You'll be faster than them (the benefit of being the "little" guy) and you're more motivated to get it done first (the benefit of the ramen noodles).
If someone else is already developing it, and you're looking to stop them because "you had the idea first", well, tough luck. With these things it's almost always first-to-market that wins.
There are two issues to address here. Patent and copyright. Ideas, and concepts can be patented before they are implemented. Copyright only applies to the actual implemented work/code.
Firstly, if you just want to prevent the idea from being patented by someone else, all you have to do is put your self in a position where you can prove "prior art", this would usual done by publishing the idea. Once an idea is published in the public domain no one else can patent it because you can demonstrate that you had the idea first. Obviously, this doesn't prevent anyone else from implementing it before you do, it just means that the idea is in the public domain so you will always be free to implement it if you decide to in the future.
If however you want to retain control of the idea yourself that is much harder. You must be the one to patent it. This very much depends on where in the world you are, but is often a long an expensive process. Depending on the jurisdiction you are in it also depends on what effect publishing first will have on your patent application. Some jurisdictions have limited windows of time between publication and patent application. If this is what you want to do you will need to talk to a patent attorney who will be able to advise you. If the idea genuinely is revolutionary, take care discussing it with anyone else before you have made the decision to either file the patent application or published to prevent others from patenting. Patent attorneys should be happy to sign some form of joint non-disclosure agreement (NDA) as part of their contract before discussing the idea.
Secondly, copyright is much easier. Copyright applies only to the actual code, not the idea. Once you have implemented the code for your idea you should publish it with a copyright and license notice. The copyright should specify yourself (or your team) as the owner(s) of the work. The license should tell other people how you are going to allow them to use your copyrighted work - when you speak of open source licenses you are probably thinking of a specific kind of license that permits free usage and modification of your copyrighted code (The two aren't necessarily the same, you can make your code open source, but still restrict its usage in your license - Microsoft have done this with lots of their code). It doesn't grant anyone else ownership. You still own the code, but depending on what you put in your license will depend how free others are to utilise the code themselves. What's important is that the copyright and license only apply to your code, not your idea. If you didn't patent the idea, anyone else is totally free to re-implement your idea themselves in their own code regardless of your copyright and license restrictions.
[Edit: I'm not a lawyer - If in doubt seek professional legal advice]
You can't really copyright an idea, only patent it - which (usually) has a much more rigorous acceptance criteria. However, if you preemptively publish your project with whatever code you do have written, under a license like GPL or MIT License, you are restricting others from taking outright the result of your work - that codebase and related assets, specifically, are copyrighted. This will also ensure that no one else can patent it, since a patent must be original (no prior art).
If you just want to make sure that no-one can patent / copyright it before you, simply write up the idea and 'publish' it. This creates prior art, and would prevent another party from patenting the idea after your publication date. You've got a better case down the line if you publish in a known / respected journal, but this can obviously be quite difficult if your idea isn't sufficiently academic or formalised. However as long as it's out on the web etc. and could be shown to have existed from when you claim then it should in theory suffice.
Bear in mind that this doesn't stop someone else from implementing your idea, they would just not be able to get any legal protection (i.e. a Patent) on it. Of course this does put your idea out in the open, so someone could come along and implement their own version before you.
The only way not to loose the idea is not to execute it. You can feel warm about having a good idea for as long as you wish before executing it. Ze Frank had one The Show about it.
Open source does not mean that you give away copyrights. Open Source is just a licensing method for others to use your copyrighted code. So add a copyright notice to your code and protect it. The fact that it's copyrighted doesn't mean you can't share it. You're just allowing others to use your code, according to the license you add to your code.
You should ask anyone with whom you discuss the idea to sign a Non-Disclosure Agreement, and possibly some form of Product Submission Agreement. You may find, however, that many companies, particularly those who undertake their own research, are not keen to sign this type of agreement.
If you have serious plans to make money from this, you need to talk to an IP lawyer. If you go down the Non-Disclosure Agreement route you'll need professional help in creating the NDA document. If you go down the patent route, you'll need professional help (+ money) to prepare the patent application. And so on.
(IANAL ... and you won't find legal advice here.)
Good ideas are often overrated.
Skype isn't the first voice-over-ip service and there were dozens with that idea before Skype.
But because Skype did the execution better than everybody before them they reaped the profits.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Contributing to open source can have many forms: working with issue trackers, patches, further development, documenting, funding, etc. Assuming your company uses open source projects, what is the single most important reason why you're not contributing back to the community?
Developers cost us money. Open source does not cost us money. Hence, if we start giving developers time to work on open source software then open source loses its competitive advantage and we may as well give MS a call since at least we can define how much money they cost us upfront.
We do, we're founded on Open Source - but I guess we're special ;)
Anyway, this is not like a true answer to your question, but rather an answer to the "questions" in the other answers I guess. There are many ways to contribute to Open Source. Sure you can contribute code, but the other thing you can contribute is money by donating. Jeff Atwood (one of the founders of SO) did this a couple of months ago to a wiki system system I know.
When I worked for my previous startup we gave WatiN $300. This is a contribution, and probably a both a better (and at least cheaper) contribution then having one of our coders trying to figure out the code model and coding standard etc behind WatiN and then fix some bug and supply a patch.
But the THIRD way to "contribute" to your favorite Open Source project is more subtle, but often the definitive best way you can contribute which is by giving it attention like I just did with WatiN through that link.
I am willing to be $100 on that someone reading this answer will check out the link to WatiN, read about the project and download it and start using it in their own test suites. And they should since WatiN is a great Open Source project and Jeroen the guy behind it is truly helpful!
That is also contributing. Helping your favorite Open Source project get some attention by telling others how great it is!
We do contribute back to open source in the one situation where it would be pure insanity not to. When we fix bugs, we always ensure that they are pushed upstream.
As I say, it would be really insane to not do that, and have the alternative of maintaining a fork.
Our management doesn't understand open source. I'm not sure that our boss understands that we are using OSS for development.
In the last time, our boss wanted to release some stuff as open source, but the package should be bundled with a support-contract, so I don't believe he really knows what Open-Source means.
So in one sentence: we don't give back to open source because our management doesn't understand the concept behind open source.
Update: Now we have an OS-product, but our management do not understand it until today. Actually we did it, because some of our customers talked about open-source (and really meant for free).
We contribute back patches and bugfixes.
We don't generally start new projects, though. We don't really have the overhead to support such a project. Unfortunately, you can't just post a tarball on a website and expect strangers to add features to your code. It takes work to build a community.
Developer time/team resources, and the "appropriateness" of contributing code back.
Meaning that, if we make modifications to an OSS project, sometimes the changes aren't necessarily appropriate to contribute back to the project. This may be because of IP rights, but actually, the most common reason is that we simply don't anticipate that other people would require such specific modifications to the software in the way that we've made it. So generally speaking, such patches don't make sense to send back to the team developing the OSS project.
In other cases, these changes could be sent as a patch to the OSS project developers, but this would require cleaning up/reformatting the code, separating out private company data from the patch, etc. Usually, if we're using OSS software in the beginning, we don't care about such things, because most OSS software is somewhat dirty in terms of code quality anyways (ie, no test cases, coding standards, documentation, etc.). Therefore, the time required to clean up our dirty fixes to already dirty code is usually more time than we want to spend for the altruism factor here.
That said, I have worked at companies that did contribute back to OSS projects when necessary, and those that did not made monetary contributions to some OSS projects or distributions.
In my opinion the biggest problem is that most companies are doing development for projects. If a project develops something that is worthwhile to be published as open source the commitment for maintenance can only be given till the project is finished. After that no more resources are available for further developments, support of the community, bug fixes etc. This usually means a slow death for the open source "product".
Also, some companies are very eager to look at the PR for things they publish, and this usually means to go through all the processes for publications. This is something which in general overwhelms engineers and programmers.
Getting it through legal. Seriously, even as a huge contributer to open source software, as a large company the bureaucracy is a killer. (Hope Legal don't read this:)
The company I work for produces software that is proprietary and our software is highly specialized and is our major competitive advantage over all the other companies in our industry. Can't imagine why Open Source isn't something we encourage.
What about a company that doesn't have developers? Maybe they're not a software group, and are using OSS to save money, a la a web-based group that uses LAMP, but never modifies any of the components?
In our case, we produce extremely customized software for the specific circumstances of a state office. Because of that, our software has no utility for anyone else. Being a state office, we aren't at liberty to "donate" time or money, either.
In theory, we could open-source some of our documentation, but again a lack of demand would make it nothing more than an empty gesture.
Business logic.
If I start building a project where I use the source code for a FLOSS project rather than just a library then I need to develop with an awareness of two factors: the changes to the code to make it do what I want and those aspects that I would be allowed to release to the world.
Generally it's not that difficult to do this, but if deadlines are tight then I'm not going to 'waste' time stripping out our proprietary extensions.
Programmers cost us money, but contributing to open source doesn't generate a cent of revenue.
We do contribute and are very proud of it !
http://hg.nuxeo.org/opensocial is all about our contribution to Nuxeo from Leroy Merlin.
Ok, i doesn't generate a cent of revenue, but it doesn't really costs more. And when people will contribute to our code (patches, bug fixes, extension), this will be code that will cost us nothing.
Moreover, our contribution is now included in the core feature of Nuxeo, so now we will benefit of a vendor certified integration of our code.
I am not sure contributing with money is the best way to help OpenSource software. When Jeff Atwood gave some $5000 to an OpenSource project the lead of the project was grateful... but if I recall correctly he was not too sure about what to do with it.
Developers who contribute to OpenSource projects are not paid to do so. They do it because they like it, want to prove something to themselves, etc... but money is never the cause since they know that they won't probably earn a dime. At best, they might attract attention which may then generate revenues (think new employer, more traffic to their blog, etc...)
Now, I don't say that one should not contribute, but I think that monetary contributions are not as efficient as one might think, companies have a tendency to think that their model (capitalist) naturally extend to everything around them :/
In my opinion, an OpenSource project benefit more from patches/bug reports than from direct monetary contribution, exceptions being hosting the website / repository of the project or financing meetings for the top contributors so that they can discuss face to face when the need arise, but though this cost money, this is not directly giving money.
Even though we do give back to open source as code patches, and releasing open source software I can understand why other companies don't. Because "it doesn't make any profit" :)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
We have a series of closed source applications and libraries, for which we think it would make sense opening up the source code.
What has been blocking us, so far, is the effort needed to clean up the code base and documenting the source before opening up.
We want to open up the source only if we have a reasonable chance of the projects being successful -- i.e. having contributors. We are convinced that the code would be interesting to a large base of developers.
Which factors, excluding the "interestingness" and "usefulness" of the project, determine the success of an open source project?
Examples:
Cleanliness of code
Availability of source code comments
Fully or partially documented APIs
Choice of license (GPL vs. LGPL vs. BSD, etc...)
Choice of public repository
Investment in a public website
There are a several things which dominate the successfulness of code. All of these must be achieved for the slightest chance of adoption.
Market - There must be a market for your open source project. If your project is a orange juicer in space, I doubt that you'll be very successful. You must make sure your project gets a large adoption amongst users and developers. It is twice as likely to succeed if you can get other corporations to adopt it as well.
Documentation - As you touched on earlier documentation is key. Amongst this documentation is commented code, architectural decisions, and API notes. Even if your documentation contains bugs, or bugs about your software it is ok. Remember, transparency is key.
Freedom - You must allow your code to be "free" - by this I mean free as in speech, not as in beer. If you have a feeling your market is being a library for other corporations a BSD license is optimal. If your piece of software is going to run on desktops then GPL is your choice.
Transparency - You must write software in a transparent environment. Once you go open source there is no hidden secrets. You must explain everything you do, and what you are doing. This will piss off developers like no other
Developer Community - A strong developer community is required. This must be existing. Only about 5% of users contribute back to the project. If someone notices there haven't been any releases for a year they wont think "Wow, this piece of software is done," they will think "developers must of dumped it." Keep your developers working on it, even if it means they are costing you money.
Communications - You must make sure you community is able to communicate. They must be able to file bugs, discuss workarounds, and publish patches. Without feedback, it is pointless to opensource the project
Availability - Making your code easy to get is necessary, even if it means pissing off lawyers. You have to make sure your project is easy to download, and utilize. You don't want the user to have to jump through 18 nag screens and sign a contract in order to do this. You have to make things simple, and clean
I think that the single most important factor is the number of users that are using your project.
Otherwise its just a really well written, usefull and well documented bunch of stuff that sits on a server not doing very much...
To acquire contributors, you first need users, then you need some incompleteness. You need to trigger the "This is cool, but I really wish it had this or was different in this way." If you are missing an obvious feature, it's extremely likely a user will become a contributor to add it.
The most important thing is that the program be good. If its not good, nobody will use it. You cannot hope that the chicken-and-egg will reverse and that people will take it for granted until it becomes good.
Of course, "good" merely means "better than any other practical option for a significant number of people," it doesn't mean that its strictly the best, only that it has some features that make it, for many people, better than other options. Sometimes the program has no equivalent anywhere else, in which case there's almost no requirement in this regard.
When a program is good, people will use it. Obviously, it has to have a market among users--a good program that does something nobody wants isn't really good no matter how well its designed. One could make a point about marketing, but truly good products, up to a point, have a tendency to market themselves. Its much harder to promote something that isn't good, so clearly one's first priority should be the product itself, not promoting the product.
The real question then is--how do you make it good? And the answer to that is a dedicated, skilled development team. One person can rarely create a good product on their own; even if they're far better than the other developers, multiple perspectives has an incredibly useful effect on the project. This is why having corporate sponsors is so useful--it puts other developers' (from the corporation) minds on the problem to give their own opinion. This is especially useful in the case that developing the program requires significant expertise that isn't commonly available in the community.
Of course, I'm saying this all from experience. I'm one of the main developers on x264 (currently the most active one), one of the most popular video encoders. We have two main developers, various minor developers in the community that contribute patches, and corporate sponsorship from Joost (Gabriel Bouvigne, who maintains ratecontrol algorithms), from Avail Media (who I work for sometimes on contract and who are currently hiring coders on contract to add MBAFF interlacing support), and from a few others that pop up from time to time.
One good developer doesn't make a project--many good developers do. And the end result of this is a program that encodes video faster and at a far better quality than most commercial competitors, hardware or software, even those with utterly enormous development budgets.
In looking at these issues you might be interested in checking out the online version of a course on open source at UC Berkeley, called Open Source Development and Distribution of Digital Information: Technical, Economic, Social, and Legal Perspectives. It’s co-taught by Mitch Kapur (Lotus founder) and Paula Samuelson, a law school professor. I have a long commute and put the audio of the course on my iPod last year – they talk a lot about what works, what doesn’t and why, from a very broad (though obviously academic) perspective.
Books have been written on the subject. In fact, you can find a free book here: producing open source software
Really, I think the answer is 'how you run the project'.
All of your examples matter, yes, but the key things are how the interaction between developers is managed, how patches etc are handled/accepted, who's 'in charge' and how they handle that responsibility, and so on and so forth.
Compare and contrast (the history isn't hard to track down!) the management of the development of Class::DBI and DBIx::Class in Perl.
I was just reading tonight an excellent post on the usability aspect of successful vs unsuccessful open source projects.
Excerpt:
A lot of bandwidth has been wasted arguing over the lack of usability in open-source software/free software (henceforth “OSS”). The debate continues at this moment on blogs, forums, and Slashdot comment threads. Some people say that bad usability is endemic to the entire OSS world, while others say that OSS usability is great but that the real problem is the closed-minded users who expect every program to clone Microsoft. Some people contend that UI problems are temporary growing pains, while others say that the OSS development model systematically produces bad UI. Some people even argue that the GPL indirectly rewards software that’s difficult to use! (For the record, I disagree.)
http://humanized.com/weblog/2007/10/05/make_oss_humane/
Just open-source it. Most probably, nobody will start contributing yet. But at least you can write on the press-releases that your product is GPL or whatever.
The first step is that people start using it...
And maybe then, after users get comfortable, they will start contributing.
Everyone's answers have been good so far, but there's one thing missing and that's good oversight. Nothing kills an open source project faster than not having some sort of project management. Not to tell people what to do so much as to just add some structure and tasking for the developers you are hoping to attract.
Disorganized projects fall apart fast. It's not a bird you just let go and watch it fly away.