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
I just played a game of RBI Baseball in a browser window.
That in and of itself strikes me as simply amazing. When I was young, the NES was a magical box, capable of providing hours of enjoyment to young kids throughout the world.
Now, decades later, I'm a programmer. And I can appreciate the programming that went into games that were developed with more primitive hardware just a couple of decades ago. In fact someday, I fully expect that code from some of these games will be enshrined in the Smithsonian.
My Programming Question:
Have any classic NES games (like RBI
Baseball) been open-sourced, and if so, where can I find code to study?
Failing that, are there any NES games for which source code is available to study?
I think it would be worthwhile to learn from their example.
For instance:
Did they use object-oriented programming?
Did they use design-patterns to keep the code maintainable?
No. At least none that I know of (and I've been searching).
NES appeared right after the 1983 video-game crash, the main reason why the market crashed was the flood of bad games, triggering the customers to not buy a single game, because there was no way to know what game was good.
So Nintendo when introducing NES (and all other consoles from the time, like Master System from SEGA), decided that only approved games would ever get released, AND making anything open source ever being a breach of contract with heavy fines, the reason for that is that by not releasing a public API, it would make "homebrews" harder to flood the market.
Today Nintendo is much more easy on the part of allowing the games, see the flood of crappy games on the Wii, but still no console allow you to use their "true" API, to avoid the flooding, there are even a issue when someone used a GPL engine (ScummVM) on Wii, causing trouble, because releasing the source of a game for a Nintendo system is a breach of contract, and GPL demands the source to be released, in that particular case the games were pulled of the shelves.
And no, XNA and PS3 Linux are not really console APIs, both impose severe limitations on what you can do with the console.
Maybe you can find homebrew, or reverse engineered games. But I guess that this is not what you asked.
Also the source of remakes and ports sometimes can be found, but these don't use the console API.
Maybe you have since found this, but Metroid (the original, for NES/Famicom) has been disassembled and the code (in beautiful ASM) posted on Romhacking.net.
Direct link.
If you're interested in NES programming you should check out Episode 91 - Tengen Reunion Roundtable of Retronauts. (Note this is episode 91 of the original run of the podcast, newer episodes can be found # http://www.retronauts.com/)
It's basically a bunch of former NES programmers reminiscing about game development on the system (and other retro systems). They occasionally dip into the technical stuff, which is all really fascinating.
I've never worked in the videogames industry, but I've read quite a bit about it and I talk from time to time with friends that do, so I'll try to explain a more or less what's the difference between a game and other application, regarding programming methodologies.
The first thing to understand is that a game is a one-off product. It's not like a spreadsheet or a word processor, where you can release new versions improving and extending the previous codebase.
The second thing, is that you need to release the game as soon as possible. Usually, the more time you spend in a game, the worse will it be in comparison with the other games of the time. This is mostly true for PC games, where hardware evolves much faster than in the console world, but still applies to a large extent (games continue to get better even with the same hardware as better tools and algorithms are developed).
The third thing is that usually games need to push the hardware to the limit. So screw all the elegant patterns that would make your code more beautiful and maintainable if they make it to run slower.
So what I would expect after dissecting an old NES game source code is just spaghetti code, most of it written in assembly with plenty of low level hacks tightly tied to the architecture of the machine.
I hope my answer is useful for you.
I would recommend looking at nesdev.com if you are interested in NES game development. They have detailed documentation.
You won't likely find source for the original games, but there is plenty of homebrew out there and a relatively mature toolchain. As is the favorite answer, google is your friend. But to get you started, here is relatively decent tutorial:
http://www.bestdamnpodcastever.com/millerblog/?p=72 via "The Wayback Machine"
NES Games were developed only (as far as I know) in assembler, and I guess the source code is long lost, after those many years.
Anyway, having assembler source code is not so far from machine code, so it may not be too much revealing as it would C or Java code.
About object orientation and desgin patterns, again, it was assembler and the 80's, don't expect any of that.
Related
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 12 years ago.
Improve this question
I’m thinking of all type of game categories. My experience is that there aren’t any open source games that really challenge the commercial ones, considered game value, graphics, sounds etc.
Apart from the obvious answer of law-suits (remember the Aliens mod that received cease-and-desist letters), the other answer is cost. It takes hundreds of people to create a game like Civ 5 (artists, managers, programmers) and the cost is immense. These people are working on it for 5 days a week, 7.4 hours per day (more towards milestones) and open source alternatives are done in spare time around real jobs (not that game coding isn't a real job).
For a good open source game take a look at FreeCiv.
Several reasons come to mind:
It takes dozens if not hundreds of contributors over several years to create a major game title. An open source project of this magnitude would need lots of followers who are prepared to stick with it for a very long time. It would also require some people who are willing to coordinate the other developers (producers).
The replay value of a game is limited. Most people just play it through once and then move on to the next title. This differs it from an open source application or library which is always useful as long as you depend on it. This probably makes it much more difficult to find long-term commited developers.
I can't think of any business model related to open source games. Nobody would pay for support or much needed changes in the source code. Nor is there any agenda that bigger companies might be able to fulfill by funding an open source game project.
Contrary to popular belief, making games is not per se more fun than making applications (At least not for me, I've tried both).
It takes about eighty people working more than full time for two years to make a major game. (Some take more -- Assassin's Creed 2 was about 130, I think -- some take less.) These people must be real experts at what they do, and you need a lot of diverse skills: programmers, artists, writers, actors, sound designers, level designers, producers, QA.
Let's say you want to make a world-class game that competes with the chart-toppers on graphics, art, sound, design, the whole deal. You need world-class people doing this work: for example, animators who would otherwise be working full-time at Pixar or Weta. To get someone to work for you full-time instead of going to Pixar, you're going to need to pay them, a lot.
A game isn't the sort of thing where you can take what would be 40 hours of work for one person and spread it across one hour of work for forty people. It takes a lot of arduous, unfun work. It's not just programming the graphics engine -- it's testing the same broken thing over and over and over again, fixing a bug that appears only on a Windows Vista machine running a particular ATI card, painting bumpmaps onto fifty slightly different kinds of crate. Volunteer hobbyists tend to "scratch their own itch", do the thing that's interesting to them and leave it to someone else to polish.
It takes a lot of capital to make a game. You need a high-end workstation for each dev, sometimes two. Big screens. Fancy tablets for the artists. Maya licenses (there's no open source tool even remotely comparable). Are you making a console game? The development kits are $10k apiece. Doing motion capture? $500 an hour to rent the studio. Hiring voice actors? SAG scale starts at $800 per day. Having Some Guy From The Forums perform the roles just won't get a professional result. Plus electricity for all this, a building to put it in.
It's expensive, and it takes a lot of very specialized expertise, working for a long time even when they're tired and stressed and don't really agree with the Creative Vision, but need to finish the job anyway. You're going to have a hard time convincing really talented people to do that for free.
In addition to the other answers, a vital factor might be the requirement of expertise. Open source contains people mostly from developer/programmer/sysadmin realm. But only developer is not sufficient to build a game. You also need artist, sound engineer etc. For example, as a developer you can spend your free time to code game, but you can not create 3D models, as that is not your part of expertise.
Some possible reasons
The market is to fast. Graphics which is now good is in 2 years old and boring. So you have to finish a game very fast.
Its easier to make a mod to a game and there is already a community, so people do that more often (and its way easier to do).
The costs are huge. Its hard to find qualified people. Good game engines license costs a lot.
The organization is very hard.
There are a lot of project which are from people who don't know how to do it. So its hard to find a good project which could have success.
There are some, but they are rare: OpenTTD and early ID games come to mind.
But, seeing as the biggest investment is in the content and tools there's no reason the code couldn't be open source without affecting revenue. In fact, as OpenTTD has shown, it can extend the life of product with patches and improvements created by the community. Of course, you need a good game to start with.
While I generally agree with the sentiment, which is basically until you see open source movies, you are unlikely to see open source games with that production quality comparable to some of the major ones.
However, that said, there are some beautiful open source games. OpenTTD and Simutrans are mentioned - which are quite retro. For some more modern gameplay, check out stuff like Tremulous and Nexiuz.
Now that EA are cannibalizing and dumbing down the Simcity franchise, I'd love an open source offering to mop up and dominate the genre. SC4 was brilliant and unique, but needs some modernization in graphics, stability fixes, and easier community interaction for updating/extending the building types or city ordinances. LinCity does not yet have anything on SC4, and sadly SC5 plays more like the bad bits of LinCity than SC4.
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 9 years ago.
Improve this question
I have been using the Open Dynamics Engine (ODE) for the last few weeks with great success. It has a very simple API and its simulations at least look realistic. (I sometimes wonder about my collision joint parameters, but whatever.)
My only complaint is that it is sometimes a dog. If I naively simulate 1000s of interacting bodies, then my performance starts to dive.
I know I can spend time with their spatial grids to reduce the load of the collision system, but before I go through the effort of tuning my code to work with ODE, I wonder if there are any other Open Source/Free physics engines worth looking at. This will be for a commercial app, so I am looking for something more solid and more battle tested than some college student's weekend project.
Building a fast, accurate, and stable solver is extremely tricky, and people like Havok are understandably protective of the technology. That said, the free systems I'm aware of are:
Newton Game Dynamics -- This one made its reputation on having a very accurate and stable solver, at the cost of performance. It's spent the last few years trying to gain performance without sacrificing the other two. It is a well designed engine and it works well, but it's still one of the slower ones out there. Not open source.
Tokamak -- Exactly the opposite. This one is awful; even their demos don't run stably. Just pull up their box stacking and you can see massive jitter. I've never been impressed. It is open source and wildly fast, though.
Bullet -- This one's lead by a former Havok employee, who is now employed by Sony (although I can't remember if that's SOE or SCEA). This is the newbie of the scene, and it is actually open source. It's got heavy Sony backing, it's nicely cross platform, and it's developed by people who know what they're doing.
TrueAxis -- A recent appearance on the scene. I don't know much about it, and it hasn't really gained a substantial community. I tend to be a bit skeptical here; it may be well written, but with a small community help can be hard to come by, and it's probably not a well tested and stable engine, compared to the others.
I'm a huge fan of Bullet myself, but I've heard some misc complaints about it. Most of them seem to center around poor documentation, or occasional problems on some of the secondary platforms like Mac. It'd still be my pick after the "Big 2", Havok and PhysX.
Bullet is awesome, and had been used commercially (eg: in the production of Bolt, and several PS3/Wii games) has support for many platforma and even nVidia's CUDA.
Bullet is free for commercial use and sources are available.
The documentation could be much better but there's a forum and a number of examples that can help when getting started.
With today's hardware, if you naively simulate 1000 interacting rigid bodies on a x86 CPU, the performance starts to dive without exception. If you want more performance right now then it'd be better to seek for physics engines that shift their workload to GPU.
CPUs have great integer math and logic processing capabilities, but GPUs have far much greater raw floating point computing capabilities.
If you still want more performance by just using CPUs then you will need to change your requirements.
Farseer is very nice.
http://www.codeplex.com/FarseerPhysics
Nvidias PhysX is not open source, but freely available for Windows, Linux and PS3.
Quote from http://en.wikipedia.org/wiki/PhysX:
Nvidia provides both the engine and SDK for free to Windows and Linux users and developers[6]. The PlayStation 3 SDK is also freely available due to Sony's blanket purchase agreement.
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 9 years ago.
Improve this question
Does anyone have any idea how it would be possible to transition from business to game programming? How would anyone get a start in game programming? It seems much more exciting and rewarding (better paying too?). But it seems like most of the jobs out of school are for business programming. Any advice or insight on how to do it or if it can be done?
This is not a direct answer to your question, "How can I transition?" But instead I'd like to recommend you not go down that road or at least be realistic about what it is like. To back that up I'll quote some stats from the 2004 igda survey on quality of life for game developers:
34.3% of developers expect to leave the industry within 5 years, and
51.2% within 10 years.
Only 3.4% said that their coworkers averaged 10 or
more years of experience.
Crunch time
is omnipresent, during which
respondents work 65 to 80 hours a
week (35.2%). The average crunch work
week exceeds 80 hours (13%). Overtime
is often uncompensated (46.8%).
44%
of developers claim they could use
more people or special skills on
their projects.
Spouses are likely to
respond that "You work too much..."
(61.5%); "You are always stressed
out." (43.5%); "You don't make enough
money." (35.6%).
Contrary to
expectations, more people said that
games were only one of many career
options for them (34%) than said
games were their only choice (32%).
Many years ago I created a couple of game development websites on my own and then was one of the founders of GameDev.net. One of the reasons I did it was to make contacts and get into game development professionally. It definitely worked, a couple of the people who were co-founders have gone on to work in the industry and I'm sure I could have gone that way too but everything I learned about the industry taught me the following things:
There is an endless supply of developers out there who believe game development would be really cool. The people hiring for the industry know this and aren't going to pay you nearly as well because they rely on this basically inexhaustible pool of people.
Many of the developers within the industry may be good with 3D or sound or many other topics but often they are inexperienced with basic software practices that you or I might consider essential. In that category I would put things like source control, test first design, design patterns, etc. Even when they know better the time crunch to get stuff out the door often makes them toss good software practices in a foolish attempt to save time.
Working on a game for two years can quickly become no different than working on any other program for two years. That is, when you have to dig around in the guts of the program day after day and deal with its bugs and only with that one game it's not going to seem all that fun anymore. In fact, you may find yourself playing other games just to get away from it for a while.
What says you are going to be working on Half-Life X or one of the few dozen cool games that come out every year anyway? Remember, somebody is out there building the game that goes with the next Will Farrell movie and it's probably going to be you. Look around at most of the dreck that comes out. That stuff doesn't develop itself.
It's quite a transition! The biggest difference in mindset is moving away from the business world's reliance on abstraction to one where you're focused much more on the particular hardware you're targeting and getting things to run within strict budgets of time and memory. Game programming is a lot more like embedded programming than it is like web programming -- you have to think about the exact memory footprint of everything and CPU time is at a huge premium.
This is even true of being an MMO server programmer, because a) the server has to answer to each client command within 80 milliseconds to feel responsive, and b) the bigger the footprint of the game on the server, the more hardware you have to buy, and that costs real money.
First up you should learn C++ if you haven't already. Almost every game is written in C or C++ these days. Game consoles have strictly limited memory, and if you allocate one byte past 512mb it doesn't slow down, it crashes; at the same time, each trip through the main app loop has to complete in 33ms or less, so we can't rely on garbage collection and smart pointers. The game-development world is one of those special applications where you really need to do all those optimizations that people here say you never need to do any more.
Also, bone up on your math. Games are built out of linear algebra and kinematics -- not just the graphics, but the state of the world and the behavior of every character and object. I like Eric Lengyel's book for game math; it's been my bible for years (though there are many other good ones).
You could try to learn some graphics math and programming as well, but this is sort of a subspecialty now and typically only a couple of people on a game team are really working at the level of DirectX calls. I suspect you're more interested in game logic and server backend, which is less specialized.
Make games. There are many frameworks to help you get started. XNA has the advantage of being a real-world product that actual games are shipped with, unlike PyGame or SDL which are quick to get up and running but have vanishingly little commercial support.
A common route people take transitioning into the game industry is starting as a game development team's Tools Developer.
These tools are often written in higher level languages like C# and are used to aid in the development of the games. For example, you might help maintain or modify the teams in-house map level editor or help develop the tools that convert one media file format into their propriatary file format.
After you have spent some time as a tools developer you can start picking up domain knowledge on the side and naturally transition into one of the many types of game programmers:
Game physics programmer
Artificial intelligence programmer
Graphics programmer
Sound programmer
Gameplay programmer
Scripter
UI programmer
Input programmer
Network programmer
Game tools programmer
Porting programmer
Technology programmer
Lead game programmer
Modern games are often made by huge and highly fractionated teams in terms of roles. So, it might be worth it to pick one of the above specialities and begin studying right away as you attempt to get your foot in the door. It almost goes without saying that you should be proficient in C++ and one of the major graphics libraries (OpenGL, DirectX, etc). Don't stress about learning both, just pick one and learn it. Generally people who know one very well can transition to the other if they need to.
If you're a good programmer you can do it, game programming requires much better understanding of the platforms and tools you use to develop the games.
I think it's much harder to get into the game programming industry than just the regular industry.
The best alternative is to create your own games, get exposure, if you're good enough you'll find your way.
There are many really good competitors though, just check out the many sites that offer free flash games, you can start posting your work to those sites.
The general story is that the way to get into game programming is to start doing it. There's no point in even showing up on a game company's doorstep without a demo of whatever you want them to pay you to do.
If you're coming out of business programming, that'll count against you and be a culture shock besides. The game industry runs on single 20-something males who can be taught that 120-hour work weeks are just how things are done.
I'd recommend keeping your current job for a while and finding a mod team or open source game that could use help. Try to find one that looks likely to create a playable game rather than vanish, at a guess I'd say it will look better on your resume than some test demos both because you'll probably be working on something more advanced than you would at home and it shows you can work in a games team.
I was wondering the same thing!
I've noticed there are a number of good game-programming books at Barnes & Nobles, probably not a bad place to start.
In general though, I'd start looking at books, maybe coding some prototypes, and start looking at what companies are in your area, what tools they use, how you could basically make yourself valuable to them!
By the way, does anyone happen to know if there are particular engines similar to what WOW / Guild Wars are using for MMORPG game development in particular (my main interest)?
I think it is not an easy switch. Game programming is not something you can learn overnight. I suspect an entry level will be quite high if you want more than a graduate salary.
A long time ago I worked in a company that worked in the online gambling field. I then decided I wanted to be engaged in more serious activities.
You really need to answer one question - is that what you want because you like it or just because it seems to be rewarding right now. In the latter case you'll need to understand you'll be plating catch-up and noone can promise the salaries will be as high as you wish by the time you get your skills high.
Maybe consider some certifications/training so that you can step-up your current career position in business programming?
If however it is what you really want then just follow you heart. Show your interest and commitment, potential employers will notice it and hopefully prefer you over a guy who has applied just because the salary was looking attractive.
On the other hand, businees developers/consultants (for example in SAP world) earn quite a generous ransom.
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
Sooo...it's only sort of programming related, but I figure it's election day, right? Is there a single good reason why they aren't, not necessarily open source in that anyone can contribute, but open source in that anyone could inspect the source?
Voting machines aren't open-source because lobbyists for the "electrical till" industry successfully hoodwinked politicians not qualified to make technology choices into buying their snake-oil. This was accomplished with a mix of anti-FOSS FUD and good ol' fashioned bribery campaign contributions.
Update: I will try to post links here from time to time that show how vendors respond to critical examination. Feel free to add your own. (Pro-OSS–only: "the man" can make his own post!)
Interesting Email from Sequoia
In Belgium, the sourcecode for the voting machines is freely downloadable.
In the context of this discussion, you might find this paper interesting:
Secret-Ballot Receipts: True Voter-Verifiable Elections
It's written by David Chaum, the cryptographer responsible for DigiCash, among other things. From his bio page on Wikipedia, I also found End-to-end auditable voting systems.
Update! Now it seems we can see if this really works: First Test for Election Cryptography.
Looking back in time now, I've read a couple of articles on the experiment in Takoma Park, and this system actually seems different from the one described in the original paper. However, it is still by David Chaum, and still supports the end-to-end audit properties. The system is called Scantegrity II.
The reason they aren't open source, is because, as Kent mentioned, it wouldn't help. You could open source the code. But there's no way to ensure that the voting machine you are using is actually running the code that is open sourced.
There is no reason that open source code is better than closed source in this case.
How you voted must always remain a secret for obvious reasons. The ONLY real safeguard is the paper trail.
I WORKED with these machines and if so inclined I would have made malicious code that flips votes the way I wanted after 10 cast ballots to defeat whatever ridiculous Logic and Accuracy tests were thrown at the machine before deployment (We never went past one test vote).
Randomly pick a certain percentage of machines and compare the paper trail to the electronic tally. If Diebold had been confident of its machines then they would have insisted that this be the last step in any election.
Security Through Obscurity!
the problem is opensourcing the software would be a no-op.
They don't have any decent cryptography, and there has been demonstrated and relatively easy ways to contravene them simply by hot-swapping a ROM chip in the voting booth, or Having a device that augments the records in the record cartridge.
Youtube: Sequoia Part 1 Those with access can hack with programmed ROM chip
Youtube: Sequoia Part 2 Logic and Accuracy Test vs Election Mode with vote-stealing firmware
Youtube: Sequoia Part 5 Manipulating Sequoia Voting Results Cartridges from Precincts
#Mnementh The bad cryptography and the possibility to swap the ROM-chip has nothing
to do with open-sourcing the code? So there is the point?
There are only 3 logical reasons for opensourcing this code:
To put under scrutiny how the votes are counted to be certain its doing it right.
For somebody to be able to modify that code for their own needs.
To put the software into public domain so public committers can improve on it.
Points 1 and 3 are blown out of the water in terms of usefulness and "proving your vote counts" because you have no assurance that the code you are seeing/improving runs on these devices.
So that leaves only condition 2 being useful, and as you are not going to own your own voting machine, and have no need for one for anything more than nefarious causes or to simply prove their vulnerability.
For the majority of cases all it would mean is that there would be more information publically available on how to contravene these machines, so you would no longer need physical access to one in order to attempt reverse engineer their software and develop compromised ROM chips for use in said devices, grossly reducing the barrier to entry for the compromise of the voting system.
Granted, even in a non-opensource state this information can still leak, and you just have a false sense of security because you assume "theres no leak, I am safe", but on the contrary, if you open source it people will assume "hundreds of people have looked at the source code, I am safe" which is an equally bad false sense of security.
People are looking for a silver bullet safe way of voting, and sadly, there is none. Not without growing a race of purified peoples whom are brought up by non-committal monks in isolationist shrines to have a breed of people simply for the task of witnessing and counting votes accurately, whom are trained to be amoral and can't be bribed to switch the vote.
( It would sort of be like the 'dark angel' series except with voting agents instead of assassins, and we all know how that show works out, one of them would go rouge, we'd trust them, and they'd screw us all )
Because politicians buy them. Anything politicians get their hands in goes to shit, because 99% of the time they're only experience is in running for office, not doing things like adequately vetting hardware and software.
Also, kickbacks.
The truth hurts, doesn't it?
There is no specific reason not to open-source the software (and even opening the hardware-layout) of voting machines. It has no security impact, as some try to state, because if closed or open source, the ROM can be switched. The machine need some sort of verifier to check, if the code loaded is really the one certified for the election. Open-Sourcing would make no difference.
Because if they were they would not be able to blame inaccurate votes on calibration-errors on the touchscreen.
The people responsible have a "security by obscurity" bad meme stuck somewhere
The people building the software don't want to help competitors
The people building the software fear embarrassment
There are not enough people in the legislative process who understand the flaws in all of the above
So far, most replies have been technical in nature, but most likely, voting machines are not open source because the company under contract to develop them has no incentive to make them open source.
If a company develops an open source voting system, anyone came come around later to support that system. And, quite honestly, I doubt the government would accept the equivalent of a SourceForge project as the basis for an entire election.
Perhaps there should be an honest-broker authority that oversees the development of an open-source voting system, and contributors to that system should be vetted before they can view or commit source code.
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.