We're developing a web site. One of the development tools we're using has an alpha release available of its next version which includes a number of features which we really want to use (ie they'd save us from having to implement thousands of lines to do pretty much exactly the same thing anyway).
I've done some initial evaluations on it and I like what I see. The question is, should we start actually using it for real? ie beyond just evaluating it, actually using it for our development and relying on it?
As alpha software, it obviously isn't ready for release yet... but then nor is our own code. It is open source, and we have the skills needed to debug it, so we could in theory actually contribute bug fixes back.
But on the other hand, we don't know what the release schedule for it is (they haven't published one yet), and while I feel okay developing with it, I wouldn't be so sure about using it in production so if it isn't ready before we are then it may delay our own launch.
What do you think? Is it worth taking the risk? Do you have any experiences (good or bad) of similar situations?
[EDIT]
I've deliberately not specified the language we're using or the dev-tool in question in order to keep the scope of the question broad, as I feel it's a question that can apply to pretty much any dev environment.
[EDIT2]
Thank you to Marjan for the very helpful reply. I was hoping for more responses though, so I'm putting a bounty on this.
I've had experience contributing to an open source project once, like you said you hope to contribute. They ignored the patch for one year (they have customers to attend of course, although they don't sell the software but the support). After one year, they rejected the patch with no alternative solution to the problem, and without a sound foundation to do that. It was just out of their scope at that time, I guess.
In your situation I would try to solve one or two of their not-so-high priority, already reported bugs and see how responsive they are, and then decide. Because your success on deadlines will be compromised to theirs. If you have to maintain a copy of their artifacts, that's guaranteed pain.
In short: not only evaluate the product, evaluate the producers.
Regards.
My personal take on this: don't. If they don't come through for you in your time scale, you're stuck and will still have to put in the thousands of lines yourself and probably under a heavy time restriction.
Having said that, there is one way I see you could try and have your cake and eat it too.
If you see a way to abstract it out, that is to insulate your own code from the library's, for example using adapter or facade patterns, then go ahead and use the alpha for development. But determine beforehand what the latest date is according to your release schedule that you should start developing your own thousands of lines version behind the adapter/facade. If the alpha hasn't turned into an RC by then: grin and bear it and develop your own.
It depends.
For opensource environments it depends more on the quality of the release than the label (alpha/beta/stable) it has. I've worked with alpha code that is rock solid compared to alleged production code from another producer.
If you've got the source then you can fix the any bugs, whereas with closed source (usually commercially supported) you could never release production code built with a beta product because it's unsupported by the vendor who has the code, and so you can't fix it.
So in your position I'd be assessing the quality of the alpha version and then deciding if that could go into production.
Of course all of the above doesn't apply to anything even remotely safety critical.
It is just a question of managing risks. In open source, alpha release can mean a lot of different things. You need to be prepared to:
handle API changes;
provide bug fixes and workarounds;
test stability, performance and scalability yourself;
track changes much more closely, and decide whether to adopt then yet;
track the progress they are making and their responsiveness to patches/issues.
You do use continuous integration, do you?
Related
How do you deal with a client who has different time estimates for the software product than yours?
I am going to describe a scenario that is not mine, but that captures broadly the same problem. I am working as a subcontractor to a large company that has a programming department. The software project we are working on is in an area that the department believe they have a handle on, but because their expertise and mine are very different we tend to get different results.
Example: At the start of the project I suggested one way of development which they rubbished as being unrealistically difficult and suggested integrating a different framework (one they are familiar with) with the programming language we are using (Python) to get more or less the same result.
Their estimate for this integration: less than a week (they haven't done the integration before).
My estimate for the integration: above two weeks.
Using my suggested way to get the result needed (including using matplotlib among other libraries used elsewhere within the project): 45 minutes. This is not an estimate, the bit was actually finished in 45 minutes.
Example: for the software to be integrated with their internal system, they needed to provide a web service for me to use. They provided a broken one, though it does work with their internal tool (doesn't work with .Net or Java mainstream packages among other options). They maintain that it is my fault that the integration has taken longer than the time estimated.
The problem is not that they don't know, the problem is that they have enough knowledge about programming to be dangerous (in my opinion). Is there some guidelines for how to deal with this type of situation? A way for expectation management? Or may be I shouldn't get involved in such projects from the start and in this case what are the telltale signs?
If a client isn't happy with a time estimate, don't do the work. If they think they can do it better or faster, tell them to go ahead.
The one thing I never allow is for my estimates to be modified. That's something that caught me out early on in my career but we learn our lessons.
If clients were so good at doing the work, they wouldn't be hiring me. I'd simply point out that they hired me for my expertise so why are they disregarding that expertise. Of course, if they were to allow the scope of the project to change (i.e., less work), that would be another matter, and one up for discussion.
If you didn't lock in exactly what they were meant to provide as part of the deal, then it's a "he says, she says" situation and, unfortunately, the customer controls the purse strings. However, often, the greatest power you can have is the ability to just walk away.
No-one says you have to do the job.
Of course, all that advice above is worth every cent you paid for it :-)
I don't know your specific circumstances.
Or may be I shouldn't get involved in such projects from the start and in this case what are the telltale signs?
My answer for sure. If you can avoid those projects, do it.
Some signs : people thinking they know how to do things when you can guess they can't. The "oh no let's not use this perfectly suitable tool because I don't know it" is a major indicator that the person is technically challenged.
first of all, it is no fun to be in such an environment.
So, if you like to have fun at your job, and you do not need to take this job for extenuating financial reasons, then simply do not take the job that is not fun.
Since that is hardly realistic in many cases, you will end up with the job and need to manage the situation as best you can. One way is to make sure there is a paper trail documenting your objections and concerns with the plan. Try not to be overtly negative, but try to be constructive and present valid alternatives. Here you will need to feel out the political landscape, determine if the 'boss' will be appreciative or threatened by your commentary, and act accordingly.
Many times there are other issues that management is dealing with that you are not aware of. Be cautious of this fact, and maybe ask the management team if this is the case, again without being condescending or negative.
Finally, if you have alternatives that take less time than the meetings it would take to discuss them, just try it in a sandbox, and show it off. This would go a long way to 'proving' your points. Caution here is that you could be accused of not being a team player, or of wasting resources, or not following direction. Make sure this is mitigated by doing these types of things on your own time, or after careful consideration of how long you are spending on these things as well as how vested your boss seems to be on the alternatives.
hth
I ran into the same problem with integration. Example: for the
software to be integrated with their internal system, they needed to
provide a web service for me to use...They maintain that it is my
fault that the integration has taken longer than the time estimated.
Wow very similar to what I was experiencing with a client. The best thing I can suggest is to keep good documentation. In the end that is what saved me. When it came to finger pointing I had all of the emails and facts in order and was prepared to defend my self.
One thing I would suggest is to separate out a target/goal and an estimation. I would not change my estimate unless it involved actually removing features or something is revealed that would make it easier. Tell them you will try to hit the target in anyway you can and you care about the business goal. However, your estimate will not change. If its getting no where and they are just dense then smile and nod and take it if its the only gig around.
Was just writing about this in my blog
How to estimate the WRONG way
My team and support a large number of legacy applications all of which are currently functional but problematic to support and maintain. They all depend on code that the compiler manufacture has officially no support for.
So the question is should we leave the code as is, and risk a new compiler breaking our code, or should we bite the bullet and update all the code?
The answer is totally dependant on the resources your employer (or yourself) can afford to make the refactoring (or even totally rewrite big parts).
So you should first estimate how much time/developers you can afford to refactoring the application, then see if you think it'll be enough.
If you can afford time and people, then do it, don't hesitate! You're investing in the future by reducing the time to debug the application so it will be helpful and less expensive once the refactoring is done.
It depends on the nature of the applications, just how big and important they are, as well as the programming culture at your workplace, and the resources available to you.
If the applications are valuable enough to you that they are worth the trouble, and you have the necessary resources, then do the update. Don't let the problem persist.
If they are not valuable enough to be worth a full-scale update effort, or appropriate resources are not at hand, perhaps work on updating one at a time if possible.
Just some suggestions, but again this greatly depends on you and your organization.
It sounds like you have a large technical debt. This debt is only going to increase unless you do something. Both things you mentioned are options, and risky, but long term it's a risk you need to take.
Using an updated compiler just means you need to update the code to work in the new compiler. Something is bound to break, but then refactor the parts that break. This allows you to migrate.
The other option is to update your entire code base. This takes time, during which you need to maintain 2 copies of the code, or freeze the old version. Freezing the old version is probably not an option.
I would recommend using an updated compiler and fixing what breaks. This allows you to add features, while refactoring and fixing the current codebase.
Rewriting the code can be an useful step for you company for many reasons:
you can use a new compiler and a more recent platform
you can refactor the code deleting its weaknesses
you can motivate your people because developing new code is better than correct bugs in an old one.
Why don't you start that activity with a small number of people, beginning from the most common parts of the code? You can group them into a dll and use it also for future projects.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
As many of us do, I have lots of software ideas, a couple of really good ones, and not enough time to do everything. (I am a developer, but only one). I would like to open source some software and ideas in progress but also retain direction and vision of the project. Up until now I've only worked in non-free-as-in-beer software and it escapes me how open source could meet my need for control of it.
Let me be clear I don't intend to commercialize open-sourced projects for money. That much I know. I just want to have control of my vision which I start.
To control my own open source project I would need to manage it by providing guidance but that facet escapes me also, about how to manage something that's effectively free.
Am I barking up the wrong tree?
I've gone through this cycle myself, and can tell you you're way out in front of the horse with the cart. Not to sound harsh, but there's a frame of reference you should definitely gain.
First, "control my own open source project" -- is conflicting. Open Source involves giving something away, in this case to a community. So, thinking about control and ownership of something you've given away is a mental hurdle you need to cross.
Second, you need someone other than yourself willing to participate in your project. Without them, you won't have anyone to divert any direction and vision you might have.
Third, control in terms of project guidance is earned in any open source projects with any sort of following. It doesn't matter if you're the original developer with the initial idea; if the community is willing to follow your guidance, they will. If not, they'll simply not participate.
Enough soapbox. In terms of project management, divide the role into two functions:
1) Getting developers involved, taking on tasks, code reviews, guidance and direction, etc. Trust me, this is as much a sales job as it is credibility-based. Top-down, hierarchical, seniority-based I-was-here-first type of expectations is a sure-fire way to drive volunteers away from your project.
2) Repository logistics. In the end, you can control who are/are-not committers, their permissions, etc. If you do #1 well enough, this will take care of itself.
As a last bit of commentary, open source projects are not easy to get off the ground. There are more projects than people willing to put forth the amount of sustained effort necessary to give your project legs.
Good luck!
Well, Captain Bligh, it all depends on how you hand out commit permission, now, doesn't it? If you make the source open, but tightly control commits, then the vision is all yours. Assuming, of course, that you can find anyone else who cares enough to submit patches for your review and evaluation.
Linus Torvalds had a great speech on google talk about how he is using (among other topics) git to avoid having to include all code from the open source community! It is deffently worth checking out!
You probably can't have your cake and eat it too. If you open your source under a "real" open source license, then anyone who wants to would be able to start their own project. You could maintain control of the "real" project. Then it is a matter of waiting and seeing which version users like better, and which version attracts most of the community. You will always have control of "your" branch of the project. What you must accept is that someone else may become more successful with your original code than you are, and thus also have control.
In general, there are more ideas out there than there are developers waiting to work on them. So your real problem will likely be getting anyone to care about your project enough to contribute patches, let alone care enough to usurp control.
Even if you make the source available in a repository for anyone to grab, you still maintain control over the repository: you decide who has access, you decide which patches are committed (or at least, you decide who gets to decide which patches are committed).
However, this doesn't stop people forking your project and taking their forks in a different direction. There aren't any easy ways to prevent that: some people are ornery and will fork every project they touch, while other people might just have a different idea about how your code could be useful.
The best way to minimise forks is to be engaged with the community: be involved in discussions on the direction of the project, accept patches that add features that people want (while maintaining your own coding style and standards of course). If it's easier for people to work with the community and you than it would be to maintain their own fork, most people won't bother forking.
Of course, this means you've ceded some control to the community, because if you stubbornly refuse to give them what they want they're going to make a fork..
Sounds like the missing ingredient is some enthusiastic developers who love your ideas and are prepared to work for free.
I don't think they just pop out of the internet; you will need to go find them.
And once you find them, you need to keep them interested, which may well mean giving up some or all of that control...
Ask yourself what is your goal here–to deliver a software innovation to the world, or to have a pet project?
Well it just depends on what kind of project you are opensourcing.
Are you opensourcing one tightly defined core functionality in a small library, like a Ruby Gem, or a PHP PEAR Package, or are you looking to create the next Wordpress where millions of users have an opinion?
I would suggest starting small. Use something that you've written before, and can be used by others:
A jQuery plugin.
A Wordpress Plugin.
A PHP PEAR Package or a proposal to the Zend Framework.
A Ruby Gem that creates a behavior that can be used in Rails.
A module, or add on to some open source CMS.
Create a specific functionality that you want. Put it somewhere that other users can fork or branch your code, but don't let them merge back to the main branch or trunk of your code.
That way people can work with your code, but ultimately, you have control of what goes back into the official project.
Basically, you can't.
You can't prevent someone else fork your code and start a new project.
At most what you can do is to pick a license that says the source code can't be used to the same product ( I don't know which license is this, but it exists )
And secondly, what you can do is to have a very good control of existing base and a list a features you want to include.
If your project is forked, your new features will make less attractive the other.
Finally, your project will be forked if you don't work on it and leave it die. Otherwise nobody will come and fork your project when you're doing all the hard work right?
Here's a couple of interesting videos on the subject:
http://www.youtube.com/watch?v=-F-3E8pyjFo
http://www.youtube.com/watch?v=0SARbwvhupQ
If it's open source, at the end of the day you cannot control it - anyone will be free to fork it and go on their own sweet way. The way to prevent this happening is to be a "benevolent tyrant" and take on board other people's views on the project's direction. This assumes anyone else is interested in what you are doing, of course.
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 7 years ago.
Improve this question
I know this is a general question, but I'd like to hear other people's opinion about our case:
I work in a small company. Our main development tool is PowerBuilder, which is a very limited IDE with a shrinking community. We've created some tools, which we use internally to solve a certain needs. They have neither been properly designed nor properly tested, and are not in production quality. OTOH, they do save us quite some time, and might help others as well. I'm sure other companies have the same kind of tools, and was wondering how common a practice is it to share them with others. As I see it -
The pros:
Good karma
More attention to our website
Perhaps getting fixes and improvements from others
The cons:
Without investing more development, the tools might make us look bad
Publishing of the code requires some effort
Some of the tools might be too specialized for our needs
The whole effort might go unnoticed given the shrinking community
Have you or your company ever contributed such tools, or used such tools developed by others? Is it worth the effort?
EDIT:
For those how wondered, the tools I had in mind include -
A tool that makes using SourceSafe easier, by listing objects that are checked out to the current user or others, backing up checked-out objects, and reconstructing PBGs.
A tool that recognizes PB controls at runtime, like Spy++ does (requires some infrastructure at the target app).
PBNI wrapper for SQLite (in-process access, no ODBC).
An SQL client, text measurement tool etc.
"Open source" originally meant you published a tool, and you made the source available. Because of some projects that expected, and in some cases through licenses demanded that changes to the source code be resubmitted for sharing, "open source" now quite often adds the concept of collaborative development to the mix. I did (or attempt to do) the latter; allow me to share.
There are magnitudes of difference between the effort associated with source available and collaborative development open source.
Leadership: You need to tell people the who, what, where, when, why and how of changes. And very possibly, you'll need to diplomatically poke and prod your volunteers. You may need to define the vision and prioritize goals of the project, and then enforce them when someone tries to take things another way. And, unless you only want people to come across your tool through serendipity, you'll have to advertise, running that very thin line (even thinner on the Internet) between attention-getting and gaudy. If the project is going to implement the concept of meritocracy, as many open source proponents say should happen, then someone will have to judge people's accomplishments and dole out the rights and responsibilities appropriately.
Work flow: I haven't done an exhaustive search by any stretch of the imagination, but I have yet to see a collaborative development platform that did all the things I needed. Part of the point of open source collaborative development is that the quantity involved in code review will cover any potential issues in quality of code submissions; I haven't seen a free tool integrated into a collaborative development platform that helped manage that cleanly yet (e.g. counting code reviews; auto-promoting after x reviews). We had to handle that, hacking manual methods into the existing tools. Probably at some point you'll have to define a version and create a build. Then there's the grunt tasks like documentation. (Ever try to release a new version of something free without release notes? The furor!! grin)
PB-specific issues: PowerBuilder is a commercial tool, and while there are cheap versions available, there are not free versions. The DRM added to PB11 has probably reduced or eliminated piracy that developers were probably doing to take copies of their office PB home, and while PB11 and later have a dual license policy that would allow developers to take home a copy legally (with permission and cooperation of the original license owners to create a second license), I don't see a lot doing it. (No scientific study, that's just what I see.) That cuts down a lot of potential collaboration, even from enthusiasts. Issues of compatibility of code between versions of PowerBuilder, plus the fact that very few people will own every version, will limit again your list of potential contributors.
Don't get me wrong. I'd love to see more collaborative development open source in the PowerBuilder community. I'd love to know how to work out the issues myself, and I have an effort in the works to see if I can make a new model work. (My first effort to follow the popular model failed miserably, IMHO.)
Is there a reason to feel badly about firing a ZIP file up to the web and forgetting it? I don't know. Is there any more pride or embarrassment in a 4 year old ZIP file as opposed to a SourceForge project whose last contribution 3 1/2 years ago was a post "Where the heck is everyone?" There is a reason why Sybase CodeXchange devolved from a collaborative development platform to a source available platform: next to no one was using the collaborative development features. If you source available open source your code, you'll have plenty of company.
BTW, CodeXchange may be an answer to your concern about visibility to the PowerBuilder community, although you'll lose the web site traffic. The PowerBuilder Web Ring is another, significantly less effective, method to help your visibility that keeps traffic on your web site, but it demands a navigation bar on the target page on your site. CodeXchange may also be a way to get over your concerns about code quality and narrowness of purpose of what you have to share. grin
What should you do? Don't underestimate the effort with a collaborative development sharing, but don't let it stop you from a source available sharing.
Good luck,
Terry.
You can probably discount one of your cons: Anyone interested enough in this kind of tool to be evaluating your offering is unlikely to be writing Company X are teh suxors on your feedback form; rather if they find some deficiency in what you have put out there, you are likely to get helpful bug reports or even patches.
If you can get your company to buy off on contributing to the community then I would go for it. it is always worth the effort to give back a little bit and this would definitely be a good way to get some of your tools out to the public and improved upon by the community.
As far as the cons go, I wouldn't worry too much about the criticism, it can only help you guys improve the next product you deliver and people will respect you from learning from your mistakes, nobody is perfect.
Even if your effort goes unnoticed by your shrinking community, future employees and clients will see that you are contributing outside of the company and may help with your reputation with them.
I think the pros far outweigh the cons on this one.
In short: go for it. I doubt there's little to lose, but much to gain.
The pros:
**Good karma*
never a bad thing to have.
**More attention to our website*
possibly a con if your code is really bad :)
**Perhaps getting fixes and improvements from others*
this is possibly the best thing you get from open-sourcing your code. Its all about sharing and helping each other, you get to use other's code, they get to use yours and everyone's gained from the trade.
The cons:
**Without investing more development, the tools might make us look bad*
I'd search through to remove dodgy/rude/stupid comments, tidy up the formatting etc.
**Publishing of the code requires some effort*
requires barely any effort - set up an account in Sourceforge, create a SVN repo there and import your code. Then create a binary package (a zip file will do) and release it using the website. Might take you an hour, if you stop to read all the documentation.
**Some of the tools might be too specialized for our needs*
You could set the whole lot up as a group - eg PowerBuilder Tools, then people who see the really specialised tools won't have wasted their time getting them, they'll still have the 'more readily useful' tools.
**The whole effort might go unnoticed given the shrinking community*
Possibly, but then there's really no reason not to release the code. If you don't it may get completely lost to everyone when/if you change development tools.
Publishing your source is a great way to get feedback. If you look bad because of it, that's ok. Just be willing to fix the problem. If you want help with your improvements I can't think of a better way than asking for help.
By the way, plenty of open source projects can be credited with the growth of communities that were previously shrinking.
I think you've done a good job of identifying the pros and cons. And it's probably true that the pros will outweigh the cons. If no one likes the utilities and does nothing to or with them, then you've lost nothing really; bad code shouldn't scare experienced developers (most experienced developers, especially PB ones, have seen their share of legacy code). If even one person benefits, then you get the karma, eh?
If you proceed to submit your tools to the open source community, do as you have here, and admit up front that the tools are not polished. This may deter some from even looking at them, however, if they are at least functional and can be easily modified, then they still represent a head-start for any prospective beneficiaries. As a PB user myself, I would be curious to know more about free tools that can give us an edge in productivity.
Have you looked into Sybase CodeExchange? They have some open-source PB things there, including the PowerBuilder Foundation Class framework.
I just saw your response to my question - amazing that you have developed something similiar already. :-)
Regarding your question: the company I work for has a specific section on the web site where tools which we used internally and/or simple solutions (or code snippets) which customers frequently ask for are published. The license of these offerings is very liberal as well, I think it qualifies as open source.
In your particular case, I'm fairly interested in the Spy++-like application you talked about since I was looking for (and/or trying to develop) something like that myself.
I'm aiming for something which doesn't require any infrastructure in the target application, but so far I'd be happy to play with anything which works, even if it requires modifications to the applications. I'm just not familiar enough with the PowerBuilder API yet to make a judgement on whether this is possible without modifiying the target application.
As I mentioned, I already developed similiar Spy-like applications for ordinary Windows applications as well as managed code applications (which require interaction with the VM to query the state of the object tree), so my hope is that I'll be able to find a solution which does not require any target infrastructure.
Do you have the source code up somewhere already? It doesn't need to be compileable, I'd just be happy to look how you did it in principle so that I can (hopefully) derive something from it which solves my particular problem. In case you didn't upload the source code yet, maybe you can provide some email address which I can use to contact you privately? I tried looking for something on your profile, but so far - no luck. :-)
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.