When asked "How do I make a website?" how do you answer? [closed] - language-agnostic

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
A (non-technical) friend of mine has asked me how to make a website. I get this question all the time. After a few questions I found out that she has an idea that could turn into a commercial site. I described three options to her:
a) Get a book/enroll in a class/follow some online tutorials and learn how to do it. She's pretty smart and her personality seems like a good match for this sort of thing so I'm sure she could learn but she doesn't have a lot of time spare. Maybe if she started with one of those WYSIWYG editors at first? I stressed that this would take a longer than a couple of weekends of playing around.
b) Hire someone to build it. Ranges from ultra cheap to ultra expensive, crappy to good and everything in between. I didn't mention sites like Rentacoder because she hasn't worked on a project like this before and doesn't know what to ask for. At this stage she'd likely ask for a Youtube-MySpace-Google for a few hundred bucks because she doesn't yet understand just how much is involved.
c) Find someone technical and partner up with them. I explained that this can either work really well or be a disaster because she'd have to give up some of her ownership of the idea.
How do you respond in these situations?

Depending on the nature of the required website (ie whether she needs shopping carts etc) I often recommend first creating a blog, although it's often not the best format, it can be used to quite good effect at times. I've seen a number of small retailers for example, using a blog to advertise their wares.

It depends on the person and their motivation. Your friend sounds like she should take option b) or c). She's probably not so much interested in the technical aspects of making a web site as she is in seeing her idea come to life, or maybe running her own company based on the idea.

Well in general there are several steps:
Determine the subject of the website.
Determine the target audience.
Decide on a general layout and look and feel.
Decide which techniques to use.
Design the overall structure of the site.
Collect content and images.
Implement the site.
Most of the times, these steps are carried out by more than a single person. Because they all require their own specialization.

I think that the only realistic options are B and C. Non-techies will almost never come to grips with real web site development. With all due respect to those who have advocated technologies such as ASP.NET or PHP - it won't work. In fact, you are likely to be fielding questions for weeks on end as to why things don't work. You'll have to bear these questions until the person, having failed, gives up.
If they have the resources, then I would strongly recommend the "hire an expert" route.
In either realistic case, they must get a legal agreement in place. If she does hire an expert, be sure that the agreement expressly stipulates that this is a "work for hire". If your friend doesn't demand a work-for-hire clause then she will have no legal means to stop the developer from using the exact same code she just paid for in creating a competing site (at least in the U.S.). Just to emphasize: they would have no legal means to prevent the developer from starting their own competing site without a work-for-hire clause - the courts won't even hear the suit.
Now, if it is really just a brochure site or something similar, and they still want your advice, then it depends on whether they use a Mac or something else.
If they are a Mac user, I tell them to try booting up iWeb and using it to feed a .me account. Just plug in some pictures and some text, upload to your .me account and you are done.
If they are a Windows user, I direct them to Register.com or a similar online Web Site template-based site builder.
For your sake, don't volunteer to help unless you are really sure you have the time to essentially build the whole thing for them! You can ruin friendships this way: friends and family, having no clue what really goes into the construction of a site, almost invariably assume that it is "trivial" for you. If you delay or fail to get things done quickly enough, they'll almost always assume that you are blowing them off and they'll resent you for it (can you tell I've been there?).

It depends on how confident she is that this thing will succeed or, alternatively, how unwilling she is to share ownership. I'd definitely not recommend (a) for something that has commercial value. Beyond the time-to-market factor, initial impressions are something that is very hard to overcome. If she has the cash and is possessive of ownership, then (b) could work well. It's a bigger financial risk, though.
I'd probably go with (c), but then again I'm on the other side of the equation. There are lots of ways of structuring a partnership that would help her maintain ownership, though probably not complete ownership since no one wants to work for nothing. Some combination of b/c is probably best - some less pay in exchange for a small stake in the business. I'd definitely see a lawyer before doing (c) and maybe even before doing (b) just to make sure any agreement she has with the developer precludes them taking the code and running.

There are really two questions here: should she learn how to write a website and, if so, how.
If she has a commercial idea and she only wants to learn how to write websites to market it, I would suggest that she does not bother. Outsource instead.

If you have someone who to trust then only 3rd option is realistic. first one takes years to give out good result and with second one you never know what you get.

Buy her a book for her birthday on ASP.NET or PHP.

A bit of topic but here it goes...
We have ONE web designer at our company(we are about 10 programmers), we usually make some jokes like: "You do not work, you just sit there making drawings all day long" (just for the record, she is very competent and does her job pretty well).
So one time she stares at my monitor for about 2 minutes while i am working on a web application, and at some point she says: "Sooo that's what you do? Formulas and stuff?".
From that day on we all say "I do formulas and Stuff" when asked for what we do at work, as for most people, saying that and saying you develop web applications is the exact same thing.

Developing a web site is not as trivial as places like GeoCities or Google Pages would make it appear.
Here is a list of things you need to know about or consider when publishing a site.

If she owns a Mac or doesn't mind to acquire one, I would suggest her to have a look at iWeb. Otherwise, starting a blog on a platform such as blogger would be a nice first step for a non-technical person.

I always give the same answer, HTML. I say what it does and then tell them to get a book. If they get what it is about they will follow their own course of action.

Unless you're a web designer, 'how do I make a website' is a similar question to 'how do I make a television'. You don't, you buy one. So this question is probably 'How do I procure a website?'.
This breaks down into:
Working out what you want:
What user features do you want
What do you want the UI to look like?
What admin features do you need?
Do you already have a graphic design/logo/color scheme, etc.
Finding someone to make it for you
How do you find them? Referrals? Local web dev companys? Friends?
Do you care which technology they use?
Are you going to project manage it?
How do you know they're doing a good job?
Are you clear on issues like scaling, support, maintenance?
Ideally, find a single company who is comfortable helping you work through all the issues. Less ideally but also good, find a consultant or company that will help you with the top level stuff and assist with production of technical specs that you can then take to a development company to produce.
(Edited for formatting)

Related

About to release code into the wild [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
I have a program I wrote and I have been encouraged by folks to release it into public.
What would be the best way to go about it? Just dump it on a public site and hope for the best?
How much criticism will come (on the standards, decisions made etc...) and how best to prepare for that. I have been the sole developer for this app for about two years.
And how much difference does the license (GPL, MIT etc...) practically make?
Any experiences?
A license is a good idea, even if you don't care what people do with the code - most of the time people will happily take code "as is" and if it doesn't do what they want they will just throw it away - but you never know when some idiot might try to sue you because they burned their mouth drinking a hot coffee while reading your code. You may also wish to restrict usage (derivative works etc) where someone else makes profit out of your hard work. Fron the other side of the fence, people who might take and use your product/code like to know where they stand with regard to use/copying/distribution. By asking that your name stays on the code, you can also ensure that you get vcredit for the work, and that any improvements/suggestions that happen in the wild can make their way back to you.
If you just want to give away the code wihtout much ongoing development, then a great place is CodeProject - you can release the application and write a small article describing it, and then it's up to you to decide if/when you will post updates.
If you want other people to collaborate then there are plenty of open-source websites that will support this approach.
As for criticism, you are likely to get a few mails from people who need tech support, or who want to suggest extra features. Most people are very polite though. If you wrote the program for yourself, there is a good chance that when it gets into the wild you will discover all the bits that have to be used in a particular way to work well, and all the additional options that you don't care about but which the product needs to make it applicable to a wider audience - you can get sucked into a lot of support work if you're not careful. Ultimately don't be afraid to say "no" to someone if they ask for something you don't want to support - it's your program and your time after all.
The main thing is to have fun :-)
Using a well-known, well-tested open-source license will make it easier for your users to know where they stand with regard to your code. The worst thing you can do is release your code without a license. No license means no use, since in most jurisdictions software is automatically copyrighted with no right of use or reuse.
If you don't want the project to wither away from lack of interest, you'll need to get it in front of developers. Releasing it at a large open source project site (such as SourceForge, GitHub, or Google Code) will help you get that visibility, and will provide a lot of infrastructure for managing your project. The more you do, the better the chances that others will find it, try it, and use it.
CodeProject is a good suggestion- but it really depends on the platform. Typically users of each major development platform flock to other sites for their Open Source extensions or apps. For example, lots of developers on the Microsoft stack look for things in the Visual Studio Gallery or on CodePlex. SourgeForge obviously has its own religious following as well. I would suggest promoting your new app on a site where you would go to find something like it. The Google page rank of whatever public site you use to host it will also impact how many people find it and ultimately how much criticism (constructive or otherwise) you get on the project. Licensing is always a good plan. It has been my experience that each major open source collaboration site tends to learn towards a specific licensing mechanism, so I would just do what seems to be the most popular if you don't have any specific requirements.

Explaining "Web Application Developer" vs. "Web Site Designer" to prospective clients

How do I go about explaining that I am a "Web Application Developer" and not a "Web Site Designer" to prospective clients - without talking myself out of the project?!
Often I am approached to "design a web site" for someone where it turns out to be more of a "brochureware" presentation site and less of a real web application.
While I am a highly skilled developer, I am not a graphic artist. That said, I would still like to be able to close deals with prospects without disqualifying myself. Simply stating, "I do backend work, not frontend" will quickly end the conversation, and along with it my opportunity for work.
Sure, I can just subcontract the project to a real designer and mark up his rate, but I would rather be up front with the client that I am not going to be the guy doing the actual work and they would be paying $120/hr for $60/hr work.
...and then they will ask price - is visual design often quoted hourly like app dev is, or will I get sucked into the oblivion that is fixed fees?
First thought: You sound like you're a good developer, which is a great foundation in this situation because people feel that we have a broad understanding of technology -- and they're right! You're correct in your insecurity though - a good developer is not exactly what they're after.
They want a solution, and if you can become the guy who knows how to navigate all the complexities involved in delivering that solution... Well, then you're the guy. And you're much more valuable.
And you don't have to stop coding, either. Which has always been my phobia.
So that's more or less how I present myself to my clients. I'm a developer, but I'm also a competent project manager. I know how to take your project from here to done even though it may involve designers, IT guys, additional developers, datacenters, etc.
Working with other professionals: You probably aren't in a position to hire folks. That's fine, but find good partners, and you can market your self as a shop or consulting group that is good at more than one thing. Believe me, people will appreciate that! For instance, we have a fantastic partner in Romania that we use for a lot of design, and we add value because we know how to get results from them and handle all the communication and so on. My customers don't want to talk to 3 to 6 people, they want a single point of contact who is accountable for all of it.
One thought here: try to find people who do this full time. Moonlighters and people doing side jobs have constantly let me down. I sympathize; I know what it's like to be spread too thin.
Fixed prices: You will probably have to deal with fixed prices, and you will need to hold your partners to fixed prices (or have some other mechanismf or controlling costs) if that's the case. Once the relationship becomes more comfortable, I usually try to give clients a range of what I think a job will take -- 5 to 8 hours, etc. And I let them know that fixed prices are a little bad for them because I have to assume some risk, which means they get charged more.
Most companies still want actual fixed prices for larger projects though and many large companies are shockingly comfortable with being overcharged in this situation. Fixed prices seems to be unfortunate fact of life in the contract development space.
First of all, I think you're exaggerating a bit - you don't really want to have a $30/hour designer working on a $150/hour website. If you do, and your client doesn't notice a difference, they deserve what they get.
And if we're talking about, say, $60 - $75/hour range vs $150/hour (which, IMO, is more realistic), you have to count in the time you spend working with said designer, so it's not like remaining $75-$90 goes directly into your pocked with you doing nothing.
If I am a client, I want a FINISHED PRODUCT and I'm paying YOU to deliver. Consider yourself a general contractor. I DON'T WANT to deal with designer / tester / technical writer / what have you myself - that's what I'm paying you for. My time may be a lot more valuable to me than $90 / hour difference. I may (will) get a second / third / fourth bid if I think you're too expensive.
That said, if you need to placate your conscience you can always bill couple hours less.
I tend to say something along the lines of "My job is to develop the stuff you don't see, but that make your site work"... And that is actually quite true.
... And you might add something that says that building a website is an activity that requires several very different abilities, like :
creating something that looks nice, and is usable ; that's a job on its own ; do your client have designed to logo of their company ?
integrating this nice looking thing into a dynamic application ; that one is your/my job ^^ Your clients send/receive e-mails every day, but do they know how it works ?
administration of the hardware / server : your clients use a computer every day to go in the Internet, use Word/Excel and the like, but do they know how to install those ? How to secure their network ? How to deal with security alerts the right way ?
You can use analogies with other processes ; designing / building / using / repairing a car, for instance ; some people understand better when we just don't speak about computers at all...
The way I always try and explained it, since I'm a Developer not a Designer is.
Developer -> Makes it work.
Designer -> Makes it pretty.
Of course there are vest generalizations, but for the most part they're true.
-> Developers creates the product
-> Designers create the package
Do you bill enough hours that you could consider hiring a program manager/product owner type person at least part time to do most of your customer interaction? Because if you do, you can abstract the "design/code" questions away from the customer; let the program manager really focus on figuring out what the customer wants built.
It sounds like your average customer isn't that technically savvy. If that's the case, figure out a way to speak their language (which most experienced program managers can do). They really don't care about the difference between a designer, a developer, and a tooth fairy that shows up and delivers the site that they want.
It's also worth considering whether you really want to take on projects that are mostly web design. If not, you should work on improving your marketing materials to focus on what you do best (interactive line of business web applications, or whatever).
You can steer the conversation toward what business problem the customer wants to solve, and propose the statement of work that best matches their objective. I think this will do the most good, and then it's never a question of misleading them. It's about packaging up a solution that matches what they want.
"I do backend work, not frontend" will quickly end the conversation, and along with it my opportunity for work.
This is not necessarily a bad thing. It's generally a good idea to be honest with prospective clients, and if they do not understand exactly what your job entails up front, then they may end up expecting too much from you when the job is done, or for future projects.
If you do really want to push your services on them, you could always try to point out exactly what kinds of benefits you will be offering to them. Make a point in explaining how much value can be added to the end-product by using your expertise.
A car may look great on the store floor, but if its powered by a lawn mower engine held down with duct tape and chewing gum, the only thing it's going to be doing is looking pretty and collecting dust in your garage.

keep great ideas open and prevent theft [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
Question
If you have what you think is a great idea, how do you make your idea open source and ensure that it stays that way? How do you prevent your ideas from getting stolen and patented by someone else?
Background
I recently had an idea about a programming project that I think could be revolutionary. Being a young programmer I realize that I am going to need a lot of help to make this idea come to fruition. I also realize that there are some people who might try to steal the idea and copyright it. I don't know the steps I need to take to make sure that the idea stays open source and how to protect myself from getting the idea stolen. I don't mind if a company decides to make money off of the idea but I do want to prevent one person or company having complete control over it. I have done some searching on the web but haven't found a resource yet that answers my question so I ask you for your help. Any help is greatly appreciated.
Clarification
I'm not looking to make money from
the idea.
I didn't understand the difference
between copyright & patent but now
understand I should have asked the
question using patent instead of
copyright. (question changed)
My goal is to prevent one person or
company from locking up the idea. I
would love to have many people and
companies catch onto the vision of
the idea and run with it. (I can't
imagine what today would be like if
only one company had the rights to
produce engines, electricity, cell
phones, computers... I think you get
the idea :D
I've been down this road myself, and trust me: you can end up wasting a phenomenal amount of time, energy and money trying to protect your idea. Software patents are incredibly expensive and nearly valueless, unless you want to get in the business of suing people all the time. In any event, ideas (especially the "revolutionary" kind) are cheap; there are far more good ideas floating around than there are capable, effective programmers who can bring these ideas into reality.
If your idea is good and you prove yourself capable of executing it, you'll do fine. You're better off putting your effort into that.
As a young programmer, the greatest danger is not that someone will steal your idea. It's that no one will care about your idea. Your biggest goal ought to be to get your ideas and code -- and especially your name -- out there to get people's attention. (Not in an obnoxious way; by doing something worthy of respect.)
One of the ideas behind open source is to make it more attractive for people to work with your existing project than to "steal" it and go off on their own with a fork. Forks are a pain in the ass because you either have to keep merging in changes from the original code, or you ignore the original project and lose out on the work being done there. So it's to everyone's advantage to stay together. You want to keep it that way, as the owner of the project.
Ideally, your technology becomes popular, and as the owner/founder of the project you acquire a reputation, and a deserved position as the Big Expert on it, which will become quite valuable to you. Good luck.
I'm sure you have a great idea, but believe me when I say that a great idea is only a very small beginning. "Stealing" the idea means someone else has to invest the time and effort to take it to market. You still have to put that time and effort in too. If the system allowed everyone to claim ideas and prevent other people from implementing those ideas, we'd be in worse trouble than we're already in.
With the case of copyrights, you have to actually write something (a book, code, etc.) and you automatically own the copyright. The trick is to be able to prove when you wrote it. One easy way is to print it all out and mail it to yourself in a sealed envelope. Don't open it when you get it back. The postmark is a decent proof.
With the case of patents, you can't actually patent an idea without a design. You still have to put a lot of effort into figuring out how it's going to work.
Your best bet, if you really want to keep it a secret, is to not tell anyone. Then, stock up on ramen noodles, pizza, and diet soda, lock yourself in a room for 6 months, and build it. The chance that someone else can "steal" your idea if you do that is relatively slim. You'll be faster than them (the benefit of being the "little" guy) and you're more motivated to get it done first (the benefit of the ramen noodles).
If someone else is already developing it, and you're looking to stop them because "you had the idea first", well, tough luck. With these things it's almost always first-to-market that wins.
There are two issues to address here. Patent and copyright. Ideas, and concepts can be patented before they are implemented. Copyright only applies to the actual implemented work/code.
Firstly, if you just want to prevent the idea from being patented by someone else, all you have to do is put your self in a position where you can prove "prior art", this would usual done by publishing the idea. Once an idea is published in the public domain no one else can patent it because you can demonstrate that you had the idea first. Obviously, this doesn't prevent anyone else from implementing it before you do, it just means that the idea is in the public domain so you will always be free to implement it if you decide to in the future.
If however you want to retain control of the idea yourself that is much harder. You must be the one to patent it. This very much depends on where in the world you are, but is often a long an expensive process. Depending on the jurisdiction you are in it also depends on what effect publishing first will have on your patent application. Some jurisdictions have limited windows of time between publication and patent application. If this is what you want to do you will need to talk to a patent attorney who will be able to advise you. If the idea genuinely is revolutionary, take care discussing it with anyone else before you have made the decision to either file the patent application or published to prevent others from patenting. Patent attorneys should be happy to sign some form of joint non-disclosure agreement (NDA) as part of their contract before discussing the idea.
Secondly, copyright is much easier. Copyright applies only to the actual code, not the idea. Once you have implemented the code for your idea you should publish it with a copyright and license notice. The copyright should specify yourself (or your team) as the owner(s) of the work. The license should tell other people how you are going to allow them to use your copyrighted work - when you speak of open source licenses you are probably thinking of a specific kind of license that permits free usage and modification of your copyrighted code (The two aren't necessarily the same, you can make your code open source, but still restrict its usage in your license - Microsoft have done this with lots of their code). It doesn't grant anyone else ownership. You still own the code, but depending on what you put in your license will depend how free others are to utilise the code themselves. What's important is that the copyright and license only apply to your code, not your idea. If you didn't patent the idea, anyone else is totally free to re-implement your idea themselves in their own code regardless of your copyright and license restrictions.
[Edit: I'm not a lawyer - If in doubt seek professional legal advice]
You can't really copyright an idea, only patent it - which (usually) has a much more rigorous acceptance criteria. However, if you preemptively publish your project with whatever code you do have written, under a license like GPL or MIT License, you are restricting others from taking outright the result of your work - that codebase and related assets, specifically, are copyrighted. This will also ensure that no one else can patent it, since a patent must be original (no prior art).
If you just want to make sure that no-one can patent / copyright it before you, simply write up the idea and 'publish' it. This creates prior art, and would prevent another party from patenting the idea after your publication date. You've got a better case down the line if you publish in a known / respected journal, but this can obviously be quite difficult if your idea isn't sufficiently academic or formalised. However as long as it's out on the web etc. and could be shown to have existed from when you claim then it should in theory suffice.
Bear in mind that this doesn't stop someone else from implementing your idea, they would just not be able to get any legal protection (i.e. a Patent) on it. Of course this does put your idea out in the open, so someone could come along and implement their own version before you.
The only way not to loose the idea is not to execute it. You can feel warm about having a good idea for as long as you wish before executing it. Ze Frank had one The Show about it.
Open source does not mean that you give away copyrights. Open Source is just a licensing method for others to use your copyrighted code. So add a copyright notice to your code and protect it. The fact that it's copyrighted doesn't mean you can't share it. You're just allowing others to use your code, according to the license you add to your code.
You should ask anyone with whom you discuss the idea to sign a Non-Disclosure Agreement, and possibly some form of Product Submission Agreement. You may find, however, that many companies, particularly those who undertake their own research, are not keen to sign this type of agreement.
If you have serious plans to make money from this, you need to talk to an IP lawyer. If you go down the Non-Disclosure Agreement route you'll need professional help in creating the NDA document. If you go down the patent route, you'll need professional help (+ money) to prepare the patent application. And so on.
(IANAL ... and you won't find legal advice here.)
Good ideas are often overrated.
Skype isn't the first voice-over-ip service and there were dozens with that idea before Skype.
But because Skype did the execution better than everybody before them they reaped the profits.

what interview questions should you ask of a user experience (ux) developer/designer

We are hiring a UX consultant, had a broadstrokes session with the company, liked their work, think the candidates are ok and now want a more concentrated interview with the specific UX consultant that will be embedded into the scrum team.
What questions should be asking that could weed out any dead weight candidates.
Thanks.
Ask Tog has a good Quiz. I'd also ask stuff on the Gestalt principles, but that's probably because I have a masters degree in HCI (as in that might be a bit academic). That said Gestalt principles are very important especially for things like Form design.
I guess also you could ask them what their favourite book on UX design are, if they can't list any that would be very odd to me.
Personal Experience A good UX practitioner should be taking an interest in the things they use personally. I would ask them what they use personally - obvious technology items like phone and websites, and also less obvious things like kitchen appliances and vending machines. If a UX candidate can't tell me what they observed in their day so far (e.g. the car or public transport they used to get to the interview), that's a good way to weed out the dead weight right there.
Practical Problems As with programming, the best way to assess someone is give them a real-world problem you're facing (or faced) and see how they deal with it. Their thought processes are more important than the answer.
I am a UI Designer/Developer and once I gave an interview to Verizon for UX Designer position. By the way, it was a phone interview. I never worked as UX Designer before. The person who interviewed me asked me about my past work experiences, skill sets and asked me if have contributed as UX designer before. With regards to technical question, he actually sent me a document which had some brief information (part of an application) and then a small interface (it was like a table with some graphic based information, and based on this information, the call center people would respond to user request). I was asked to study this table carefully and then i was given 24 hour timefame to suggest a changed table/design and was asked to explain why would i suggest those changes. Just by looking at that single page document, I didn't understand the problem itself and didn't know what to suggest. I spent 23 hours just looking at the problem and on the 24th hour I did make a suggestion and send them my reply. But didn't work ..... i never heard back from Verizon.
As a UI Designer, I have worked wiith lots of UX Designer and all I know about UX design is that you have to understand the problem very carefully. You need to look for all posible solutions and use the one that would best satisfies the usesr needs. And then you must know how to create wireframes.
Ask them how they would go about designing the UI for some system. Tell them to design a solution for some domain which you know well (for example one of your recent projects), so that in the interview you can take the role of the user. Then the UX consultant will need to dig the necessary requirements from you, find out what is the problem that needs to be solved, and then designing and testing a solution.
Or if you want to make it easier/quicker, use a domain that everybody knows, so that he doesn't need to dig the requirements from you. For example design a system for finding out in which of the nearby restaurants you would like to eat a dinner. In one hour you should get some understanding of what the consultant is like.
Give them some screenshots* of example pages from a selection of sites, some of which you consider good, some bad, and in varying degrees. Ask them to point out good and bad features in each (and there is some good and bad in every site) and explain their thinking. If they fail to spot something obvious, prompt them with a neutral "what about X?" and see how they analyse it.
* finding these isn't hard, but a little time consuming possibly. Even better if you can give them access to an actual browser so you can go over the "live" elements
UX work is made up of two parts: Research and Design. You need to be clear which you want most emphasis on: someone who can grok out massive taxonomies and build wireframes in their sleep, vs someone who has hundreds of hours of usability lab experience. (You can find people who have both areas of expertise, but people often lean in one direction).
Beware of UX consultants who have never been embedded in a scrum team before. They will need some bedding in time. If they are used to working agency-side rather than client-side, they will be used to doing shortish research projects and then leaving. This kind of "skirmish" is quite different to the long-view you have to take when working client side.

How do I release/sell/promote a semi-commercial/open-source project? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I've got a framework for PHP that I've developed for about 3 weeks total, but it's quite ready to be released ... if I choose to do so. In this economy I cannot just take what I have done and release it for free and feel just (because I need the money it could garner), and yet I am torn by my appreciation for open source projects. I want to eat and I want to share as open source. I'm sure some understand my conundrum right off the bat.
As an example of the pros and cons of my project, here's a very quick comparison against CodeIgniter. My framework is 10x faster at the base speed (blank CI versus the basic demo of mine) and gets upto 20-30x faster elsewhere. Yet, my framework lacks many things that CI has like advanced routing (with regex, or named parameters) and ORM. If I was to compare it to a similar framework in another language, I'd call my work the Sinatra, or Ramaze, of PHP.
I need some extra income. This is a flat-out fact, and yet I don't want it to be a strictly commercial project.
I like open source, and I want to contribute my own work. Yes, I know frameworks for PHP are a dime a dozen, but I think I might have something here. So, I don't want to let my work go entirely.
So I remain torn. Licensing can help, but only when people are honest. I don't believe in putting "DRM" into my software. Yet, I don't have enough features to say, "If you donate/pay you'll get X other features!" and make a benefit to this.
How do I (can I) sell this? How do I promote it and release it as open-source for free uses? How do I license my work adequately for these purposes?
What is your general policy or tips for projects like this? Especially when you want a cut of the profit someone would get using your project commercially. What licenses, restrictions, etc, do you think would work in this model?
I appreciate any answers which might help me to figure out what to do.
Edit:
To clarify on what I'm thinking, let me add this: this is my pet project. It's something that I made because I felt its lack in the market of PHP frameworks, and have been maintaining it for my own works. But, unlike most my work, I would really like to make this public. I want people to see it, try it, use it, and work with it.
However, I've put in enough off-hours time into this for it to be just given away. I appreciate the open source model, but I don't see how I can just donate some 80+ hours of work for free for a speculative increase in my "reputation" within the software world. PHP frameworks are a dime a dozen and I think I've made a good one, but I'm sure there are just as many others who've done the same. Mine may be better, but it's got an equal or greater chance of being average to poor.
I'd love to release my pet project to the world under an open source license. But, I'd rather someone not take my work and make software that nets some $30k in profits, and not give me a small slice of it. I'm not being greedy--I wouldn't care if it were only $100 for a profit that large.
I am simply trying to figure out how, when, or if I even should, monetize the work that I've done for myself.
I feel that if you actually believe you have started something big, release it to the open source world. If it get's adopted and becomes a standard for many, this in itself will open many more profit making opportunities for you as the creator/inventor. The biggest potential for you to make big money (in my opinion) is to be a major player/founder of a big initiative.
To be absolutely frank, you probably have an overinflated idea of how good your framework is and how ready it is to be released (in any form).
Firstly, you said it took you three weeks to develop. Well if you can do it in three weeks, so can a bunch of other people and that's a fact.
Secondly, release of a commercial product would require having a license (count on a lawyer for this one), writing documentation, building a Website to promote the product, having some means of payment, getting a suitable legal structure to sell software, insurances (generally speaking you'd need some sort of professional indemnity--open source is generally provided without indemnity; commercial software is different), bookkeeping, accounting and so on.
Third, it's PHP so source code protection will be an issue. My advice would be to treat this as a social rather than technical problem, meaning if someone is going to steal your software, there's not a whole lot you can do. More to the point, don't hurt (or even inconvenience) your legitimate users for fear of pirates and thieves.
Lastly, one of the advantages of open source is that you can get community effort in development. You lose that as soon as you go commercial. Even if you go dual license, you can't take someone's GPLed (for example) code contribution and release it under a commercial license.
You may need money but selling software is generally a terrible way of doing it. A longer term view would be to have you build a profile and a name for yourself by people adopting your framework and the best way to make that happen is for it to be open source. Linux may be free but I can guarantee you Linus Torvalds earns a healthy income from his efforts.
If the framework is indeed good, and sees a minimum adoption after it is released, you might be able to land some PHP consulting work.
For me the main problem with new software is credibility - it might be the best software yet, but if no one is using it and if reviews are nowhere to be found, I don't want to be a guinea pig. Making money from commercial software can be very hard if you don't find customers early on...
You could try the QT model: Dual-license you framework with a free copyleft license (you'll have to check which one is appropriate) and a paid-for commercial license.
You better choose dual licence.
Its similer to MySQL.
The best way may be to ask for donations. I would definitely donate if I liked your framework.