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 5 years ago.
Improve this question
Suppose you're working on an enterprise project in which you have to get management signoff in order for you to develop a new feature set. Usually your management has no problem signing off on some bright shiny new UI feature. Unfortunately they have a hard time appreciating some behind-the-scenes issues that are crucial to the application's well-being such as transactions, data integrity, workflow routing, configurability, security, etc. Since they're non-technical and these issues are not immediately visible, it's not obvious to them that this is crucial.
How have you convinced them that these infrastructural issues have to be dealt with and that it is important to their business process?
Every craft has its unsexy sides. Things that HAVE to be done, but nobody notices them directly. In a grocery store somebody has to organize how and when to fill the grocery shelves so they always look fresh. In a laundry you need somebody who thinks about how the processes should be optimized so that the customer gets his clothes in time.
The tricky part is: The customer won't notice when these subtle things have been done right UNTIL HE NOTICES THEY ARE MISSING! Like when the laundry is not ready on time but two days late, or the veggies in the super market have brown spots and look terrible.
Same goes for IT. You don't notice good transactions until your major customer knocks on your door and tells you that an important and expensive project has failed because the database entries of your product were mysteriously mixed up. You don't notice good security until customer credit card information shows up in Elbonia (and soon after word is in the national newspapers warning customers of your company).
The thing you really have to hammer in again and again and again is that software is NOT static. It has to be cared for even after its initial development phase is over. It is not just a product you buy once and forget about. Every car manufacturer knows that services is of prime importance to the products they build, simply because things WILL occur that have to be fixed and improved. It's the same with software.
So make a presentation, visualize, verbalize, translate your technical information into benefits. Business people don't care about your wish for code aesthetics in a refactoring project, but they WILL understand that your changes will help the product to become more reliable, gain a better reputation and reduce the amount of future service requests. Make them understand by showing them the benefits!
Same thing folks have been doing for thousands of years: draw pictures. Diagram the problems, use visual metaphors familiar to your audience, drag the problem into their territory.
Assuming they're not being intentionally obtuse...
A big +1 for analogies and metaphors. If possible, find one that will resonate with the personal interests of your audience (if it's 1-2 people). For general metaphors, I often find myself using commuter traffic or subways, for some reason.
e.g. We are currently migrating an app from an OODB to Postgres/Hibernate: the bulk of this work is done in Release '4'. Many domain experts have been asking why there are so few user-facing features in R4. I regularly tell them that we have been 'tearing up the city to put in a subway. It is very expensive and undeniably risky, but once it is done, the benefits in R5+ will be astounding, truly.' The true conversation is more involved, but I can return to this theme again and again, well after R4. Months from now, I hope to say "You asked for X and it is now very easy -- precisely because you let us put in that subway back in R4".
The surest way to get upper level management to buy off on development work is to present it in a quantifiable way. Ideally this quantifiable measure is in $$. You need to explain to them the consequences of skimping on data integrity, security, transactions, etc. and how that will affect the customer\user community and eventually the bottom line. You should be careful in these situations because sometimes management expects these non-functional requirements to "just work." If this is the case, you should either estimate high and work on these items alongside the visible UI work (ignorance is bliss) or you need to document these areas of need as you communicate with management so if things do go bad as you anticipate, it's not your job that is on the line.
Unfortunately, it usually takes a disaster or two before this stuff gets the attention it deserves.
It really depends what your management is like, but I've had luck with good old honest-to-goodness fearmongering. If you go through a couple of disaster scenarios, and point out someone's going to get blamed if they occur, that can be enough to make their arsecovering instincts kick in and finally pay attention :)
Car analogies.
Everybody knows that 'system' and it's sufficiently complex to depict the dire situation.
I'm battling with essentially the same kind of situation. Whether it is sign-off by management or acceptance by a user/sponsor, the problem remains one of different vocabularies, priorities and perspectives. I asked a simmilar question here.
I also got diverse answers, tantalizingly close to useful, but not quite definitive enough. Browsing and searching SO using relevant keywords led me to find usable insights in various answers spread out over many unrelated questions. To find and extract these gems led me to pose this question on site-mining.
It would have been useful to be able to flag the various answers and see them all in a single list, but alas, that functionality is not yet available in SO. I suggested it on uservoice.
Hope you find something you can use from the references I gave.
The right kind of countering question is the secret.
Is it okay to crash every 5 web pages?
Do we have to protect the credit card numbers?
Is is okay to have to pay contractors to deploy a patch every weekend?
Did you want it now or did you want it to work?
Robustness. When it comes down to it, you need to talk their language, which is how it affects their bottom line. If its a security or correctness issue, you need to tell them that customers aren't going to want incorrectly acting products, no matter how nice they look.
I like the idea of Technical Debt, because it enables technical issues to be translated (albeit loosely) into money issues -- and money is something most managers do understand.
Although the idea of technical debt was originally applied to architectural issues, it can be used more broadly for any type of situation where there is pressure to take a shortcut -- that is, go into technical debt -- rather than do it right the first time. (Doing it right is the equivalent to saving up to buy something -- it takes time -- rather than buying it on credit and going into debt.)
Just as debts can be good (e.g. home loans) and bad (e.g. credit cards), so technical debt can be good and bad. I won't try to characterise the differences completely, but good technical debt can be tracked accurately, so that you know how much in debt you are.
So, try to explain your important, non-UI problem in terms of technical debt, and the cost of not fixing it in terms of paying interest on that debt.
A descriptive picture really helps non-technical people understand what you are talking about. For example, below is an example from Sun describing how information is processed in one of their somewhat complex applications.
(source: sun.com)
Trying to explain this application in words would be impossible to a non-techy. Pointing at the diagram and say look, this part is our weak point, we need to improve it. That will make sense to them. If they feel like they have some understanding of what you are doing, they will be far more willing to support your request.
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
I am building a 'software as a service' website that will be charging users a small monthly fee. I am considering changing the Github repository over from Private to Public. Essentially open sourcing it. Is this suicide? I would like the community to be able to benefit from the code. It is unlikely that I will accept any push request so I'm not going to gain anything in that regard. It is community based, so I think most of the value would be lost by someone self hosting it. It is for a very niche audience so I doubt someone else will start a competing hosting. I would really like the code to be in the open, but not at the expense of my idea of course. How does everyone else feel about this? What is common practice?
Conclusion, I'm keeping it closed for the time being. I may look to open source sometime after launch however.
Since you are not going to accept pushes you might as well hold on get your code stable and then publish it for others to learn and benefit from. You are still building the service, so its not going to attract too many eyeballs either.
From a business point of you, you might want to have a reasonable community around your service before you opensource it. if you are still budding who knows if its taken up by a stronger competitor. If your idea is patented its a different story.
To be honest, and this is not likely going to be a popular answer, but to myself, I would keep it closed for a period of time.
The reasons for this are simple, establish your foothold in the marketplace, build your userbase, your brand, then it gives you a mechanism to market your product further by selectively or completely open sourcing components of your system.
I say do it for both personal benefit and potential strategic benefit ... afterall, alot of software IS a service
Most open-source projects stand to provide a return in the right circumstances. Don't forget, unless you have a patent or some massive advance that is so complex and unfathomable that nobody can re-implement it .. if they want to they will anyway, so you have little protection staying closed source anyway ... even more interesting is that the open-source equivalent may well overtake your proprietary one if it garners support.
People may send you great ideas you never thought of, or take your codebase in a direction you would not have predicted. Unless you have significant value in terms of IP or strategic position tied up in the source code ... releasing it will probably do more good than harm.
Also, by being first to the open-source arena with your code, you gain control over any resulting community driven development ... if somone reimplemented your functionality and went open source ... could you compete on any front?
I know it is a cliche, but probably for good reason, but read The Cathedral and the Bazaar and the essay Open Source as a Signalling Device - An Economic Analysis which is an interesting read. Michael E. Porter's texts on competition analysis are interesting when held up against the mixed value economics and competitive forces of open source and shows how disruptive open-sourcing a product can be to competitors ... and how it can add value to your market position. Also, whilst counterintuative, it can raise the barriers to a successful entry by competitors.
More food for thought on the advantages and disadvantages of open sourcing:
What the DoD thinks of open source
Alfred H. Essa "Innovation and strategic advantage: lessons from open source" (warning, journal link)
I like to fix flaws wherever I see them, and perhaps I am one of your users. I'd rather send a patch than send a potentially nagging-sounding email any day.
What benefit are you hoping to gain from making the code open source? If you don't want the input of other developers then there are very few advantages and a whole lot of potential disadvantages.
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
Some time ago I observed a few people trying to start an open source project. About a week after the project started it more or less completely dissolved, partly due to issues with how the project itself was managed.
The ideas behind the project were however very well thought and a lot of people are still interested in seeing it realized. So far no one have made any serious attempt to recreate it but a few of us are thinking about doing so. Of course we don't want the project to end the same way it did last time.
Now to my question. How should one start a successful open source project, where successful is defined as "the project does not die unless no one is no longer interested in the software itself anymore?"
Nice question, though it's more worthy of a book than a simple article, IMHO. And I hope it comes as no surprise that most of the best advice is social, not technical.
Here are some observations in no particular order:
Don't make a big infrastructure investment up front Unless you're already an Apache committer (or somesuch), don't shop around for a sponsoring organization or host your own servers, etc. Get up on GitHub in 5 minutes and don't look back. Put your energy in features.
Lower the barrier for entry Don't make potential contributors jump through hoops or undergo a background check before you'll listen to their ideas. Open source projects are networked economies... you need the energy of others. Even misguided activity is better than no activity on your project. You can always steer the codebase in a better direction later.
Minimize custom code Don't write a custom logging tool or XML parsing API... there are open source implementations that are (1) good enough, (2) better maintained, and (3) better than yours will become anyway. The more energy you can focus on your core problem, the better.
Live on the edge People and organizations will only invest in improving your project if they will directly benefit. Eat your own dogfood. Create dependencies in your other projects (like with your employer) on your open source project, even if it isn't "perfect" yet. (Hint: software projects are never perfect, they're either works-in-progress or dead.)
GitHub is a good place because it makes it easy for someone with even just a little bit of interest to fork your project and apply his/her patches to share with others.
But it's really about the attitudes around your project more than where you host it or other simple considerations like that. Be benevolent, serious, and judicious, keep a community going even though it will be pretty small for a while, and so on. Accept patches that should be accepted, reject patches that should be rejected. Just be a good person, developer, and manager, and apply those skills to your project, and it should be fine.
You are saying it yourself. The most important thing is that it should have people who care enough about it to deal with the problems instead of abandoning.
If no one cares enough, it will die again. Try a different project where you do care enough.
"A lot of people interested in seeing it realized" means nothing if nobody will actually do the work, fight the fights and stay put.
I don't think it's set in stone, but for me the biggest point is that your project should fill a gap in the existing ecosystem. In other words, there has to a space for your project to live.
Other than that, I can say that the best way to stay motivated is to work together with people. You say that there are still a lot of people interesting in seeing it realized. So, why don't those people do something about it? Surely they can do something. I think a common misconception is that contributing to an open-source project means you have to be able to write code.
There's more to it:
Write documentation
Create graphical elements
Discuss features and roadmaps
promote the project
etc. etc.
Sure, not all of these points are applicable to every project, but trying to get people to commit to a project will eventually help you and/or your projectmembers to stay commited as well. You don't want to let down all the other folks on the project, do you? ;-)
This is kind of off-topic on SO, but I'll bite anyway.
Most FOSS projects are started by a SINGLE person. Other people come on board after this person has produced some code that does something vaguely useful. So if you want to start a project, do it yourself, set up a site on something like Google Code, and write some code. The last is the most important.
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 5 years ago.
Improve this question
We're a medium sized engineering shop (10-20). We are great at prioritizing and structuring work on our user facing stories and making customers happy. But the cobbler's children have no shoes. If it isn't about customers, we have 0 process.
I'm looking for systems to ensure we correctly prioritize and accomplish the non user facing work to keep a dev shop running: QA environments (pretty heavy, in our case), continuous integration systems, the packaging, and so forth.
Now, resources are always limited. We don't want to give the cobblers children 10 pair of the fanciest shoes, and specialized bike shoes to boot. We want to do the right, necessary work, with the same scrummy discipline that is applied to the rest of our development.
Tell me what system works for you: how to you prioritize and organize non-user facing work ? I want systems that are simple and integrate smoothly with scrum.
(I'm aware of a red box at the top of this text, indicating that Stack Overflow's automated question parser thinks this is a subjective question that can't be answered - I think there are likely 2 or 3 excellent answers that can be or have been proven viable - and process is integral to programming. So here is some psuedocode representing our process. Fix this algorithym).
IBacklog GetBacklogForWork(IWork requestedWork)
{
if(requestedWork.IsUserFacing) return new PrioritizedBacklogRepository();
// Everything else. Priority largely based on spare time and who thinks its a neat idea
return new RandomizedPriorityRepository();
}
void HandleIncomingSuggestionsForWork(IEnumerable(IWork) ideas)
{
foreach(work in ideas) GetBacklogForWork(work).Insert(work);
}
Someone involved is using and depending on the results of the project. This is necessarily true; if it weren't true, why would you be doing it?
When you identify the person who most depends upon, or cares most about, the results of the project, you have the "user" that your project is facing. Make that person the customer.
IMO something like "QA environments" is, in a sense, user-facing work.
Quality is admittedly a "non-functional" requirement (so there isn't necessarily an associated "story"). But, you may have a non-functional requirement like "the software must be tested before it's shipped". You can assign a relative priority to such a requirement ("how important is it that software be tested?"), and then execute as usual (decide how to implement that requirement, estimate how long it will take to implement, schedule the implementation, assign the implementation, etc.).
What we do where I work is to have a percentage, right now around 15% give or take a few percent, that is spent on internal tasks that are non-user facing work. This way the technical debt is handled and if the task backlog becomes rather large then a sprint may be spent on it instead of new functionality. The way that last one would get pitched to the user or customer is that there will be a time where just maintenance and preventive work is done so there aren't any new functions coming after the next sprint.
That's one idea that can be tweaked a bit though it isn't necessarily fully flushed out yet.
The way I've seen it work more or less ok is to try to do as much as possible of the non-functional/non-user-facing as PART of a related user-facing activity, or the first user-facing activity that requires it.
This is the easiest to cope with, as it just reflects the needs of the development organization in order to maintain sustainable velocity moving forward.
Additional work which cannot be related will be done using a percentage as described by JB King.
The alternative of pitching it as an investment with such and such ROI to the PO is a theoretically sexy concept, but with real life POs I've seen it rarely works.
Its very hard to get POs to understand the investment, not to mention actually being strong enough to delay functionality for it.
Its sometimes the difficult role of the development teams to be the guys that "slow things down" in order to keep a sustainable situation.
Dev managers sometimes feel really bad about this whole sitation, regardless of the chosen approach. My recommendation both as someone who's been in that spot, as well as an Agile coach, is that as long as you feel you are doing the right thing for the business, focusing on non-functional work that is required NOW and has a relatively quick ROI, you should feel ok about this.
Cautionary note: This is an area where self-organization is really put to the challenge. Organization needs to trust the team to do the right thing, and the team needs to earn and not abuse that trust. Its a sign of maturity for an individual or a team to know the right balance.
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
I am working in a small team on some projects in my spare time. We are having the problem that we seem to go in circles and are not able to get our products developed - however this is not a problem during my day job. The lack of face-to-face communication seems to have a real impact on productivity.
Any examples of software or methodologies in use by the open source development community would be appreciated.
If you read the history of most open source projects, they start with one person doing a lot of the initial work. If there's a team, it's small, and one person actually leads the team.
To pick one example. In the Python community, they refer to Guido van Rossum as the Benevolent Dictator for Life (BDFL). His word is (more-or-less) final. In many cases there are folks don't agree with him -- but for the sake of the Python community -- they seem to acquiesce to his judgment.
I think every open source project has a (singular) lead programmer who assures that decisions get made, and made in a consistent way.
Back in the olden days, Fred Brooks (The Mythical Man Month) described "chief programmer teams". Same concept. Someone is in charge of the technical content. Emphasis on the one. Nowadays we call the the "architect" or some such term.
No real methodology here, but I think 2 things are important:
Have well defined goals and
responsibilities.
Let each developer
have the last say in how their
allocated part should be done.
In open source projects the only real and strongest motivation is the fun to be had coding the product. Relating to #2 above, if people are told what to do, and they don't agree with it, the motivation starts lacking. Of course there will always be a bit of give-and-take like in any other type of relationship.
Also about the face time, Skype is great for having face to face meetings, which I recommend at least once a week or month (depending on the size and momentum of the project)
This is a difficult question to answer because "open source projects" is a very broad selection of projects. I think the defining characteristic is the project has a single unifying goal (perhaps, a set of related goals).
Are you on any open source mailing lists? I am subscribed to my favorite distro's mailing list and the developers e-mail each other many times a day. Also, there are other avenues of communication such as IRC / Instant Messenger.
I am not a RoR developer, but I would suggest skimming through Getting Real for some inspiration.
My guess is that your private projects are all run and coded by developers. Developers are known to... keep on developing. The big difference, in my experience is that a company has experienced managers that can define when things are DONE. I'd recommend putting someone on the task of defining goals and decide when things are done.
I've been on some projects where we had a lot more talkers than developers. My inclination is to ignore the talkers and listen to the coders. Even then there's usually one person who is in charge of accepting patches. There may be political issues they have to tread lightly around, but for all intents and purposes they have final say.
Linus has had some fairly famous issues with the same problem. Take note of this thread from 2006: Talk is cheap. Show me the code.
One more thing. Since you say in the comments that you do have code, just a lot of rewrites, I'd highly suggest you read Eric Raymond's The Cathedral and the Bazzaar. Eric's a bit of a nutter actually, but the essay is priceless for anyone wanting to run a Free Software project.
I'd have a think about your and your team mate's motivation and goals in this project. Are they to:
a) Create an awesome product
or
b) play around with software, and learn some new things
Both answers are equally valid, and i'm guessing it'd be a mix with a leaning towards one or the other.
If it's more of (a) then look at suggestions on methodology etc. Maybe even consider forming a company around your awesome idea. Because making such a thing takes work.. and well you probably get enough of that at work.
If it's mostly (b) then you're going to have a harder time making an awesome product, but an easier time in that you can forgive yourself for not getting there right away and suffering multiple re-writes. And you will all be learning new skills each time you look at it and work together which are very applicable to your long term careers.
Firstly i suggest you all be clear with each other on why you are there. Then look at paring back on what you are planning on doing, and release early and release often. If your project is made up of three components and one is complete, then release that as a separate component and start building a community of users. This will pay off as these users will possibly help you with your code, plus form a solid core of users for the full product and let you assess how you are going early rather than later.
Good 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.