As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have my moments of inspiration like many others -- most of them bad, with a few diamonds in the rough. Is it possible to monetize those diamonds with stakeholders or entrepreneurs without actually being the person to handle development and technical? Any avenues that you can recommend would be appreciated.
Yes it's possible but also you should consider this:
From Getting Real
Awful idea = -1
Weak idea = 1
So-so idea = 5
Good idea = 10
Great idea = 15
Brilliant idea = 20
No execution = $1
Weak execution = $1000
So-so execution = $10,000
Good execution = $100,000
Great execution = $1,000,000
Brilliant execution = $10,000,000
To make a business, you need to
multiply the two.
The most brilliant idea, with no
execution, is worth $20. The most
brilliant idea takes great execution
to be worth $20,000,000.
That's why I don't want to hear
people's ideas. I'm not interested
until I see their execution.
However I think it's possible make a draft and show it off to seal a deal.
It's possible, but consider this: how much value is there really in an undeveloped idea? You're not the only one out there with great ideas you can't implement.
Having said that, if you really think it's new and original, you might as well use the broken system to your advantage and look into patenting it.
Ideas are a dime a dozen.
Getting them out the door is where the real work is.
There's a lot more to a new product than just an idea and software development. Frankly, these are two of the easiest parts. Marketing your product and getting people to actually buy it - that's the hard part!
Depends on the nature of the idea, but if all you have is an idea, but no work, you're unlikely to find a buyer who will pay you a decent amount.
No.
Everyone has ideas. They are a dime a dozen. Less than a dime a dozen.
Ideas without implementation are wothless. You can neither get, nor deserve, any money without anybody doing any work.
Start a business, get a business loan to fund your business early on. Pay people to work for you developing said idea. Once you have early prototypes then you can start looking for outside funding and try to make returns on your initial investments.
It is possible to sell an undeveloped idea but probably almost impossible to protect it. Consider this, no matter what you do competitors are watching for quick solutions.
The only real means of protecting a niche in a market is to be the best at it, to gaurentee that a replication of your product will be a waste of money, because it will pale in comparison, due to your head start in developing the product.
In short if you can't be the best at your idea, it will be replicated and you'll be outcompeted.
Therefore,
If, and only if, you're convincing (or crazy) enough to find someone who can competitively produce your idea will you be able to monetize the idea.
In general I would say no. Investors will at least want to see a prototype.
If your idea is amenable and you are willing to do some work, you may be able to take your idea and sell it as a consulting engagement to a company. You can structure the agreement to keep the rights to your software. I've worked on a project like this before.
Of course, you could always build a time machine and travel back to 1995 where you could sell ideas without having anything built.
You said that you have potentially money-making ideas, in moments of inspiration, and that most of them are bad. I suspect most of us are like that.
How do you tell which ideas are bad and which are good? It's usually impossible to do so without trying them out. If you're willing to go out and work on one, you're at least showing that you have confidence in that one. If you aren't willing to, why am I to have confidence in your idea? Give me some reason to believe somebody (perhaps you) thinks it a good idea. (Alternatively, you could try patenting it, which last I heard cost about ten thousand dollars or more in the US, but that could also turn me against the idea.)
How do you handle a situation where I might have had the same idea, and for whatever reason didn't pursue it? I'm not interested in giving you money if I implement an idea I came up with independently. If you tell me the idea, I can always (honestly or otherwise) claim I had it also. I'm not interested in signing anything that restricts my actions in the future (like the ability to profit off an enterprise without cutting you in) unless I get something for it. I'm also not interested in putting myself in the crosshairs of a lawsuit if I start a business and you think it was from your idea. I have no business reason to listen to your idea unless I already have some confidence it will be profitable to me, and for that see the paragraph above.
Ideas come to everybody. I have ideas. You have ideas. Why should I pick an idea that gives you a cut of the profits, when I can pick an idea I had myself? Sure, I probably overestimate the value of my own ideas, but you probably do also.
You see people making lots of money for no particularly good reason, an author cleaning up on a book that's not all that good, a financial analyst getting millions while bankrupting his company, that sort of thing. What you don't see is that those people put in a lot of time and work to get into that position, where they could profit unfairly. If you're willing to put in that effort, maybe you can get an undeserved profit too.
So, if you have an idea that could be worth millions, get a start on it. Don't try to profit from it without something to show, preferably something that shows off advantages without giving away the whole idea. That shows that one person, at least, has some confidence in the idea. It puts you out in front, if only slightly, and demonstrates that you're probably the logical person to keep going with the idea. It allows you to discuss possible ways to exploit it without giving away the whole thing. It allows me to save face; rather than admit that you have better ideas than mine, it allows me to finance you on the basis of something tangible. (Never expect somebody to pay you just for being smarter than they are. If you are, they won't want to admit it. If not, well, why should they pay you?)
I run a small software shop and over the last 20 years I've had dozens of people approach me with ideas. Most were users who were thrilled to simply see their ideas brought to fruition. Some were convinced, as you appear to be, that they had the "next big thing" and just needed a programmer to make it work. One guy actually sent me a "non-disclosure" agreement that would have, in essence, given him ownership of everything I developed in our field forever after signing the NDA. His "logic" was that his idea was so wonderful that anything I ever thought of after hearing it would be colored by his brilliance! Obviously, I threw it away and he faded into obscurity.
My take is that ideas are free, period. If you don't have the wherewithal or initiative to turn your idea into a real product, or even just a prototype, then you simply have no claim that anyone else need honor. My apologies if this sounds harsh but I've simply been at this too long to buy into the proposition that the people who do the actual work should owe anything to people who just free-associate.
If you do put in the effort to make the idea real, then you are owed the full protections of the copyright and patent laws to the extent that they apply.
First : You should discuss your idea with people you know who are good in that technical domain. They will tell you if 1. The product is worthy 2. There is nothing like it in the market already.
You could then try venture capitalists with your market analysis. There you might have to justify as in why you don't want to develop the product but want the money up front.
There are people who would buy the idea but the chances are slim if there is no prototype at least.
Genius is 99 percent perspiration and 1 percent inspiration.
-- Thomas Edison
If you don't have the time to develop your idea, you might have to be satisfied with giving it to others and watch it flourish. Or else, found a company, hire a CTO and CEO, and offload the implementation work. You might then have to be satisfied with only a small fraction of the company.
Professors give away their ideas to "student entrepreneurs" all the time, trying to get them to actively perform implementation work. The professors would co-found and then provide consultation to the company.
Yes, it is possible to sell idea/s. But before that just google it if your idea is already implemented or already stolen by someone else. Its a huge world with common thoughts. Every time google disappoints me by showing number of results of my (so called unique) ideas. But keep trying, you may be Genius.
Get yourself a sales guy that has no problem selling "vapourware".
Then when he's sold a version of it, code like mad to get it done.
Unethical, maybe, but if you can pull it off, it'll get a startup up and running nice and quickly.
How do you know it's a good idea? Evaluate your idea, assess the market it will play in, identify experts or talent that could implement the idea, create a rough marketing plan or launch plan, make some blue sky revenue guesses, and figure out the next smallest possible step towards realizing the idea (that is, plant your first milestone).
Now bounce all this around friends, and business people asking for evaluation. Take it to your local Small Business Developer Center and see if they have advisors that you can meet (most have some type of network of retired executives).
If (and it's a big if) you have the capability to implement the idea than yes, you might get angel round funding, a business loan or a team of excited volunteers willing to sweat for equity. That first milestone is key for some investors - "Fund me to this point and then we'll sit down and look at what we've got and re-evaluate and hopefully decide to continue funding."
Ideas are cheap. Implementation takes money, time and especially effort. And it's effort that is valuable.
If you just want to jot down your ideas and sell them, just write a book of ideas.
I would probably buy your idea if it would be so great.
For me ***the lack of idea is the issu***e, I would stand up for its execution (after its evaluation of course).
Not sealing a deal here, but startups would not be able to pay for the idea, instead they would be able to make you co-founder, stakeholder or similar when they will start implementing your idea.
Related
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.
For example, can an experienced coder with limited C#.NET experience be successfully paired with an experienced C#.NET coder with the secondary aim of getting the former up to speed with C#.NET?
Absolutely. Sharing knowledge is one of the points of pair-programming (along with the useful dynamic of having one person type for a bit and the other review as they do it).
In my experience, it's one of the most effective ways of doing so - and allows the less experienced coder still to usefully contribute (it takes less experience to review what an expert is doing and make sensible comments/interventions than to do the entire job).
That depends on the personal chemistry between them. If the more experienced programmer is willing and able to share his knowledge, and let the less experienced programmer participate in the development through writing code and discussions, I would say that it is a very efficient way of learning.
Yes, I find good pair programming is always two way, it's essentially a piece of social engineering masquerading as an IT innovation.
Yes, this will work. If 1) the programmer with limited experience is receptive to learning C# and 2) the other programmer is willing to teach C#.
When the skill mismatch is high, then it does become more of a teacher/student relationship. This isn't bad, but can waste time of the skilled person.
However, even if it's impractical or a waste, it can be very useful to have a very occasional pair session! Even if the student is overwhelmed or it's awkward, sometimes it's useful for "students" to see how people of top level work and think. It helps give them an idea of the problems/skills/methods of high quality work. Think of it as a high school student visiting a research laboratory. It's a waste for the pro scientists to teach the high school student, but the 1 hour visit can help focus the student and give them a glimpse of the ultimate goals...
I remember why I chose Emacs as my editor. I just happened to sit near an expert user, and literally rudely peering over his shoulder I watched him rearrange and navigate code super-quickly. I only watched for less than a minute and I never talked to him.. he may have not even noticed I was watching! But I was floored, and decided to learn Emacs. Ten years later I still don't have as much skill as that expert, but I don't regret my decision to change editors, since I got a glimpse of what was possible.
Personally, I think that would work well and is one of the goals of pair-programming but how successfully will depend on the two programmers. If programmer 1 (the one learning C#) was putting in some extra time to truly get up to speed and programmer 2 (the other one) has the patience and desire to teach it should be good for both.
You can certainly do this - we've done it in the past. But you have to accept that you trade off the "code quality" benefits against training benefits. There's no free training ride, I'm afraid.
It works to some extent. Usually it's one leading the other... so it's not much pair programming in that sense.
It depends heavily on the experienced coder's skill to teach and the other coder's skill to learn quickly.
Yes, but only if the better person is patient and willing to teach and the worse person is willing to learn. I've pair programmed with people not as good as me and it was tedious, but I think they learnt from it. I've pair programmed with people that are better than me and I certainly learnt from it. Depends on the people really.
It can be effective with the following caveat: You must switch partners.
I've actually been in this situation and, if the gap is large, it can be very taxing for both members of the pair. Best to switch partners after a few hours, with the time varying according to your tolerance and the size of the gap. If that option isn't available, mix in some solo programming.
There's a saying that a team's strength is as good as its weakest link. Pairing the strongest one with the weakest one has traditionally been the best strategy because the weakest learning from the strongest potentially ensures most amount of learning. If there is a worry of the strongest being uninterested, then replace the strongest with someone who'd really be the strongest.
It all depends on the personality of the developers there is no hard and fast rule.
One thing that is certain is that the experienced developer will be less productive when working with an inexperienced developer. I personally think there needs to be a good match of abilities when pair programming. It is however a very good way of getting inexperience developers up to speed.
Although its a good idea but practically it may not be useful. To train somebody you can organize training and assign mentor who can help and guide. The mentor can assign work from the real project and may monitor.
Pair programming should be between relatively experienced people, if you want to get the benefits of this concept. In my view pair programming with an inexperienced person will have loss of productivity and not sure how much the person will pickup when somebody is constantly checking on him. Assigning a task and giving chance to develop it independently and then review it will provide good self learning.
Yes, but the approach to make it effective may not be clear at first. The task that is being pair programmed on should be the task of the less experienced programmer (We will call him Michael). I would also have Michael start the pair programming session so as to explain what the objective of the session is. This approach puts Michael in the drivers seat where the more experienced programmer (We will call him Bill) will serve more of a mentoring role.
Typically Bill will either take or be given more complex tasks to work on. This approach allows Michael to work on tasks that are more suited to his experience level. I would recommend switching off at 30 minute to hour intervals at first such that Michael can get used to the process of giving someone else control. You can slowly shorten these switch offs to 15 minute intervals or whatever works best for the two developers.
I think that the final results you get depend on the guys that are doing this. In this case, you'd probably end up with one leading the other (and where the other is just paying attention to understand the language features the first one is using).
It depends on how much skills impedance mismatch we're talking about.
Two good programmers in different languages can grow-up quickly with it, obviously at the cost of a little slowdown of the one expert in the current project's language.
If the difference is too big (for example, a veteran and a rookie), instead, it might be preferable to start with some other kind of approach, to avoid the risk of getting highly counterproductive.
Always beware the extreme pair programming !
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I have written presumably some of the first code to modify the memory of a popular new MMORPG in such a way as to create a macro framework, allowing for advanced automated reactions, skill/level gain, large scale data retrieval, and botting.
It's my supreme pleasure to automate tasks in this way, I can't help but think of any manual approach as "broken". In fact I find myself rather unable to complete even single player games before dissecting their mechanics and gaming them, in a specifically read-only (not cheats, per se) mouse and keyboard input only fashion. Supplementing my advancement toward a game related goal with my own programming knowledge seems natural, it's really not fun otherwise, like ignoring your firearm in an FPS.
Since I love this form of reverse engineering I assume others do as well, they'd appreciate the end result at least. I tend to feel a project should somehow "ship": be sold, open sourced, or freely distributed. "Happiness only real when shared." Otherwise it's just me and my timesink.
The problem is that there are several moral stances involved with a project of this nature:
An evil is released upon the virtual world. Those with the program have an advantage, the game is unbalanced, you've got to use, simply to be on equal footing. It's no longer about the game, but the tools, an arms race. It's like every other MMORPG. Therefore, keep the code private.
The above is inevitable, so release a peremptory free distribution to give players equal access to the advantage and potentially deny someone else a more evil™ (e.g. elitist, commercial, etc.) release. Between evils the least is selected, though its necessity is disagreeable.
Sell the program, reap the benefit of your proclivity, it's work for which you deserve recompensation, fair trade (and regardless of ToS violations). Follow the likes of WoWGlider. Is it better in fewer hands?
Keep the code private. Respect at least this much of the company's Terms of Service you agreed to.
What is a morally defensible approach? What haven't I considered? In my experience ToS agreements are a largely ineffective form of dissuasion, and the gaming of MMORPGs (and subsequently results described in #1) is indeed inevitable, but there's something to be said in not pulling the trigger yourself - or is it not so bad?
I did a poor job on the original phrasing/titling of this question, I was really looking to see if there were special circumstances when it could be morally defensible, not whether or not it would normally be, in hope my code could have constructive purposes.
As a new user I didn't realize 99% of the responses would be immediate, before my update. That said, I still received some very helpful answers regarding commercialization and the original question merited the answers provided, so: well done on that front.
I do have my answer: despite the inevitability of bots, don't pull the trigger yourself! Be the change, etc. (#3 was never on the table for me personally, but elicited some brilliant answers.)
You need to tread very lightly.
MMOGlider was a popular WoW bot up until recently. I wrote an addon for it in C# called GliderTools (GliderTools.net) which made a decent bit of money.
Blizzard recently sued MMOGlider for $6 million dollars and won. There is legal precedent now against the writing of bots and commercially selling them. The monetary damages associated with doing this are staggering. It worth noting that the crime Blizzard was able to get MMOGlider on wasn't "botting" but instead, copyright infringement. They claimed that because the bot client had to access and copy certain parts of the running games memory that this constituted copyright infringement.
Considering MDY (creators of MMOGlider) made less than $2 million dollars, they have a heavy price tag on their heads. Michael Donnelly the original creator and founder of MDY was not protected under his LLC license and he is personally liable for those $6 million dollars. This kind of debt does NOT go away with bankruptcy. He has it for life. Once you add on legal fees, appeal, etc this is a dangerous game.
I personally love writing bots. To me a game isn't fun unless I've dissembled it, wrote a patcher for it or automated it in some way. This what makes the game fun for me, not the game itself. Seeing your bot run autonmously for the first time is a real high. However, if you make a commercial product and sell it to others it becomes a different matter.
So, if you decide to make a bot I strongly suggest you either release it from outside the United States or keep it private among friends.
Earning money on annoying million of other players, on something that's close to be taken for illegal won't look good on your resume either.
Use your skills for good™, not evil.
Personally I see botting software for populare games, is like writing botnet worms.
You waste other people's time and efforts (and often money).
Would you write a virus to earn money?
I've been building (but never selling) bots for online poker and chess for over a decade (insert promotional web link here) so this question caught my attention. I agree with #Simucal in that you need to tread lightly, especially where MMORPG's are concerned. Blizzard in particular has a draconian stance towards automation.
4.5 million copies of EULA-compliant spyware
Then again, the idea that a private company's TOS/EULA = LAW is a bit of herdthink. The moreso when that company markets to a worldwide audience across international borders. This introduces additional complexities into the TOS/EULA, which is already a vague piece of legalistic verbiage in the first place. The common practice is to structure the TOS/EULA to make it as aggressive, all-encompassing, and wide-reaching as possible. This is just good legal sense. It doesn't necessarily mean that every line of the TOS is legally binding. A TOS is a deterrent and the company will insert whatever language they think they can get away with, and hope it holds up when/if it's tested in court.
Nothing wrong with this.
At the same time, building a bot is, in and of itself, neither morally or ethically wrong. There's a very strong and convincing argument to be made that provided your bot doesn't actually "hack the servers", you have every right to run whatever piece of software you like on your machine in the privacy of your home. This is especially the case when the servers are inundated with bots anyway, so by not running a bot you put yourself at a disadvantage. Everquest PVP (for example) has been dominated by botting pretty much since the beginning.
Anywhere, there are two important criteria to consider:
Does the bot depend on information which other player's don't have?
Does the bot enable superhuman reactions, stamina, or coordination?
This puts wallhacks (unfair information) and aimbots (superhuman reaction) firmly in the "unfair/cheating" category. On the other hand, a simple farmbot is most probably NOT cheating, because the bot doesn't have access to any insider information and it doesn't allow you to do something you couldn't otherwise have done. You could, if you wanted to, sit there for 10 hours a day and farm ore or roots or whatever. It's not much fun, but you could easily do so.
This is a good acid test for whether your use of automation has crossed the line. Trying to cheat people is a bad idea. But writing a bot to essentially ward off carpal tunnel is understandable, and it can actually be a rewarding project.
But again, I wouldn't advise actually selling a bot. Because if you make any money on it, you open yourself up to the sort of retaliation #simucal mentioned.
Just because other people will make similar bots does not make it morally OK.
These games are, at the end of the day, supposed to be fun. As you said, bots turn the game into an arms race, especially if the game has any competitive component.
Here's an example from my experience with World of Warcraft: I wanted a specific item crafted. The materials for this were hideously expensive on my server; the large number of rich players (who may or may not have gotten their gold legitimately) had pushed the prices up to a point where I couldn't afford it.
My only option was to farm the materials myself. Many of these required killing huge numbers of monsters for days at a time. One particular item had something like a sub 1% chance to drop. And almost every single farming spot was being run continuously by bots.
It's hard to compete against something that doesn't sleep or take breaks. You can't simply wait for them to go away because they don't. Because I played by the rules, my goal was made far harder than it should have been.
It's hard to have fun in the game if there are people willing to ruin your experience out of laziness and greed.
So no, I'd say it's not morally defensible. You know full well that what you create is going to harm people.
The real question is, do you have a problem with that?
If you've described your true feelings here, then the fun was in solving the problem, not in creating a product. If others appreciate this kind of thing they'll do it themselves.
In my opinion, you cannot have a morally defensible position when in order to being solving the problem interesting to you, you agreed to terms and conditions prohibiting you releasing your work.
The problem with this is that it reduces most of the game down to just one thing: end-content.
Take World of Warcraft for instance, I love playing that, and I love leveling up a character. Sure, there are some tedious points in the process, but by and large, it's fun.
Now, if I had installed a bot and just put it to work leveling up my character, at least doing all the repetetive work and leaving me with just visiting a trainer NPC and getting my new skills once in a while, then all I had left was the things I could do at level 80.
Additionally, all the skills I, as a person (not my character) should've learned along the way goes out the window.
There are two types of people that are beyond good in Counterstrike, as an example, it's the people that use bots, and it's the people that have just played so much that they are that good.
Once you resolve to using bots, you're pretty much doomed to keep using them, and trying to automate your end-content playing as well, since you really don't have the experience to play at that level.
So basically, you're reducing the whole game down to a programming contest.
Even if you keep you code only to yourself, all you've proven is that you can program. You've yet to prove that you can play the game.
So in the end, what actually is the point of you playing that game then?
As others have said, there's many options available to you if all you want to do is create software to automate things.
Having said that, I share some of your joy of controlling my environment. I use regularly quite a lot of addons in World of Warcraft, but they don't give me an advantage over others in the same way a bot would. They might make it easier for me to organize my inventory, let me keep notes inside the game, or just prettify the user interface, but in the end, it's still me that pushes the buttons in response to game events.
And that's what gaming is about for me.
Progression requires unethical choices. My advice is Go Ahead and "reap the benefit of your proclivity, it's work for which you deserve recompensation [...]". Why are you ever worried about this? Release the hounds and let others fight it if they can. Take a history book to see thousands of similar decisions made. It pushes humankind forward.
I'm a big multiplayer gamer myself, and played so many MMORPG.
When I see someone cheating in an online game only one sentence is out of my mouth "What a wank*r!"
Morally it's wrong to mess up other people's fun, and if you try to make money out of it it's not any better than running a SPAM company.
To be honest personally I don't care about farming bots, playing a game which requires constant farming sounds stupid to me anyway. But still there lots of people out there who cares, and you these tools definitely spoiling their fun.
I understand it's a fun challenge, keep it private have your fun, tell your friends and show off, but do not kill other people's fun.
In my opinion a ToS holds no one back [...]
So, by using the MMO, you agree to the ToS; but it's OK to break the rules, because you don't agree with the ToS? Nice doublethink, but the court would probably ROFL at such argumentation.
You see, the basic idea of ToSes everywhere is "it's our way or the highway" - by using the service, you agree to play by the service's rules; if you don't like the rules, nobody is forcing you to use that service, you can freely walk away.
Also, don't try to be "clever" and release the bot in Elbonia just because its jurisdiction allows that: the ToS probably states that server's jurisdiction applies (which can bite you if you ever decide to visit the country in question, or even another country which has extradition agreements with it).
Disclaimer: IANAL
If you been following the Blizzard versus MDY case, and the recent outcome, I would strongly recommend you to keep code in private if you're located in the US, or any country with Intellectual Property laws.
Also #3 , selling it will only get you into trouble. MDY went bankrupty, is not allowed to sell their product anymore, had to hand over the source code, and pay Blizzard 6 million USD in damage.
The author, Michael Donnelly, is likely to end up in dept for the rest of his life.
I recommend you keep it private.
As opposed to Blizzard and WoW, take a look at Ultima Online and OSI as to they allowed 3rd party tools, and even supported them (Tugsoft's UOAssist).
To me it's morally fine, if the game is designed in such a way that grinding one thing only leads to grinding another thing, and if the grinding in general is done in really unpleasant manner then, hey, why not? If it's allowed, everyone has an equal chance, as everyone can use the particular supported 3rd party product, this is a chicken-egg question.
It's mostly forbidden because it reduces the time you need to spend in the game, effectively reducing the time you're paying them for their service, so, greed or fun?
As a sidenote, I'm all against unattended macroing, it's a huge difference between attended and unattended.
Yes, it is fun to reverse engineer games and to do automation. From your question it sounds like you're asking where to go from there.
A) It violates the ToS, so you shouldn't use it yourself.
B) It violates the ToS, so you shouldn't sell it.
My impression is you're looking for an OK to do one of those two things, while admitting that the fun was in writing it. I would suggest you take the entertainment value from writing things for what is, and assume your "fun" time is not worth any money. Particularly at the expense of others.
The ToS holds no one back? Check with Blizzard, they are not pleased by such things It's definitely in their ToS not to run any programs that mess with WoW). The companies running these MMO's try pretty hard to stop such programs because they lead to unfair advantages and ruins the economies.
If you like doing these kinds of things, you can also look at non-MMOs. There are plenty of games (e.g. TES:Oblivion and Fallout 3) that have very active modding communities which are tolerated and even supported by the game developers.
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.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Does anyone have any suggestions on how to mentor a junior programmer ? If you have mentored someone did you follow any process or was it quite informal ?
If you've been mentored in the past what kind of things did you find most helpful ?
Try to set aside between 30-60 minutes a day to review their code together. If you can't do this, then try to get together to review their code whenever they make a code commit, unless it was very basic. Have them explain why they chose the approach they took in lieu of others. A process like this helps to establish a great relationship, as well as really stimulate the student to think on their own and be able to defend their decisions. Not only does the student end up with someone approachable whom they can trust, but you'll notice an improvement in their quality of code and logic almost immediately.
Edit: Also, If you are unable to commit this much time to co-review with your junior, then you probably shouldn't be mentoring them and instead see if anyone else has a schedule that would allow it. The whole point of mentoring is to actively aid in the professional development of the student, and they're not going to learn much if proper attention and guidance is not given to them.
I had the chance to work as an intern (one of two) in a small software company and had the opportunity to work on an "almost new" project they had. They had me set up with everything needed and gave me an introduction into what the project actually was (basic stuff like what the requirements were etc).
At first we got to do minor tasks like researching things that mattered to the project (they had given us a list of topics). This was, I think, to see how much we could handle ourselves, as the things we needed to look up and research were not that trivial and it took a good 2 weeks or so (counting the basic demos we had to create for it). That testing phase was actually done really without much 'coaching'.
However, after that period we could work on the actual project itself. This was also the moment we began to be coached together, in a similar style to pair programming, except there were three of us (2 interns and 1 'coach').
We learned a lot from him, but it was in an informal manner, and he didn't act like the 'all-knowing-listen-to-me' guy. When we had suggestions he would listen and think through with us whether they were any good. or give his view on why an idea should not be done in that way... Now that I think of it, he actively encouraged us to make suggestions, and to think about better ways to do things, instead of just sitting there 'taking orders' from someone who probably knows what to do better then you.
So in short:
Let the junior programmer work (mostly) on his own to study the materials at hand, give him a list of minor TODO things like looking up information, or building small demos.
Check the work he has done regularly and advise him if there are better ways to do things. Also point out the items he actually did well, that way he'll remember those for later.
Let him work on a real project, and mentor him by working together at the same project, giving him advice when he has questions.
The effort has to come from both directions: encourage him to ask questions, to challenge 'the way it is currently done'. Ask him questions on how he thinks it should be done and give him your opinion as well.
Make it 'enjoyable' - don't let it look like you are giving orders.
During an internship w/ a large company that had a lot of in house IT, I was paired w/ a mentor. The practice definitely aided my career development, both in terms of technical skills and business skills. Here are some of the reasons the mentoring worked out so well:
Credible: The mentor had 8+ years of experience and an accomplished background to draw upon in leading and training. He'd been through different challenges, worked in different environments, so he had a great perspective.
Genuine: The mentorship was encouraged by the supervisor, but not so formal as to make it an exercise in going through the motions. The mentor wanted to mentor, and I wanted someone to learn from.
Passion: The mentor loved the field he was in, the problems he was solving, and the technologies he was using. When I came under his wing, I found this to be infectious.
Sharp and Articulate: The mentor approached issues critically and framed them concisely. There wasn't a lot of fuzziness in our discussions; we got to the root of the matter and he directed me on wise courses of problem solving and action.
Meaningful: The work I was doing w/ the mentor was meaningful work, not just an exercise to keep busy or ramp up in a skill set. By jointly working on a task that tangibly aided the organization, that helped focus my interest and legitimize the mentoring process.
At my first place of employment there was this really patient dude that would always help me solve my immediate problem, and then teach me some important underlying principle. I loved this because he would help me stay productive while teaching me how to become a better programmer.
I'd be the junior, I guess :) I think I'd value an informal approach. It probably depends a lot on your and your mentee's characters, but I'd say that you learn best if you don't have egos in the way. Break the ice, make sure there's feedback in both directions. Things like code reviewing (both ways?) and occasional pair programming may work, and if there's a good match, it may be a lot of fun, as well!
Because I had to explain why I wanted to co-op (besides needing the money) during my interview, my manager made sure my first project allowed me to work on what I had identified as weak areas: very little Linux experience (I chose a Linux-only R&D team so I would be forced to learn), not knowing a useful text editor (I really wanted to learn Vim), and how to learn another programming language (very different approach than learning a language as you learn to program). He told me I was being paid to study for a while.
I learn best by reading books, so after chuckling over Unix for Dummies (yay! I wasn't the only one who thought this was obscure and knuckleheaded sometimes) I started with Unix in a Nutshell and Sobell's Practical Guide to Linux Commands. After that I printed out the Vim documentation and started going through it. Then I looked through a couple books on Python, the language of my first project. I was given all the time I needed to feel comfortable about these things (which was the real problem, as I now understand) and then began adding functionality to a previous co-op's project.
I realize now it would have been terrific to meet with someone every day or two for code review, as Kamikaze Mercenary said.
In my experience, when mentoring someone, it is very important for the mentee to really WANT to learn more.
Never ever spoon feed them. Instead point them towards things of value and have them utilize the new information they are learning in projects that they are using. Knowledge is useless if not put into practice. So encourage your mentee to code, code, code.
Here would be my short list:
Pair programming - This is helpful for many things, like reinforcing various ideas and practices. Getting used to Resharper is much easier when you pair with someone that uses it often.
Informal chats - This is where we would go get a drink, go outside for someone to have a smoke break, go for lunch together, etc. While away from the desks, the discussion may be related to work immediately being done or it may be abstract philosophical stuff that can help bring someone's game up a notch or two. Talking about various upcoming technologies or changes in what coming can be exciting and help form bonds as well.
Feedback and suggestions - This is what occured in both above cases. Books like "How to Win Friends and Influence People" by Dale Carnegie can help in understanding various human relationship dynamics, which while that sounds quite technical is really just about how to motivate someone else in various ways. A key point here is to know how to leave a trail of breadcrumbs to pick up some practices, like giving hint after hint about something rather than just give the answer. I have had various Math teachers that had a gift for this for how I developed some of this skill.
So part of this is merely motivating the other person and trying to guide them as when someone figures something out for themself it can be an empowering and enlightening experience. The, "I did it! That's right, moi, yours truly!" kind of self-talk is quite nice when it happens.
Ask them what would they try next to complete the task. This can give an idea of where from the "I don't know what to do" to "Well, I would try this but..." category are they in terms of having their own idea that may be useful for a starting point.
Take a quick look at what they want to do and offer hints so that they figure out the problem. This is rather than give the answer of, "Just take out this line of code," suggest they look at what is there and is it all necessary
I would recommend start giving parts of real assignments you have and make everything to be able to use his code. In other words train him as replacement for yourself.
This way you will commit yourself to allocating time to work with junior and he will be able to see "real life". By working on real assignments and hearing lively feedback he will be able to get p to speed rather quickly.
Drawback of this approach is that it is possible that it will have too narrow focus on you particular project. So be sure to show the trainee possible alternatives and encourage trade-offs analysis to widen his professional horizon.
Couple of years ago I worked for a small company, where on the first day I was given a list of small task to complete - do some little changes in code, find and fix a small bug in the project. It really helped me to ask the right questions from my mentor and familiarize myself with the environment, the code base. These tasks were easy to complete, so I had a little bit of self confidence, before turning to the bigger tasks.
This way of mentoring really worked with me very well, so I am planning to do the same with our new colleague.
I have mentored several junior people under me before. My approach varied slightly based on the person a bit based on how they learned.
In short, I gave the junior people small, self-contained projects when I could and gave them a relatively fixed time to complete the task. Once the task was complete I would review their approach, code and solution and made suggestions for improvements or a better way to handle the problem. I think this way they don't feel overwhelmed being part of a much larger project.
Hope this helps a bit.