|
CodeWraith wrote: This is the holy grail of practical jokes
Not bad, but I still prefer Bert (from Sesame Street) making an appearance on Osama Bin Laden propaganda posters.
|
|
|
|
|
Hello, I like to write code sometimes as a hobby. I happen to work in retail, and coded an app for use at work. I have shown this app to my management, and a screenshot of the app ended up going to even higher management. If my manager was being serious, they are talking about paying me for use of my app. I live in the usa. Is there any special information on anything regarding this? I am used to just posting my stuff as open source and free. Never thought that I would ever be asked this question. Wouldn't even know what to charge or even how to charge. One-Time fee, Yearly Commercial license, per download fee, etc. Your thots?
CLWPROGRAMMER
|
|
|
|
|
If you turn it into a product, then support and maintenance will go with it. If it is truly useful, the more you will be asked to make numerous changes to it and support those too. Since your bosses know it is your app, it will have higher expectations than an app that is purchased somewhere. If it breaks and you fix it, you are just doing your job. If it breaks and you don't fix it, your job security will be on the line.
I'd give it to them for free. Don't exercise visions of grandeur.
If this ends up getting you a new job description, go with it, but don't be cocky about it.
I'm retired. There's a nap for that...
- Harvey
|
|
|
|
|
I'm intrigued to know what this app does....
I wouldn't give them it for free, that shows you don't think it's worth anything.
I would decide if you want to support and maintain the app or just offer it as a done and dusted piece of software that they can purchase.
It is a bit of a sticky one as they will expect you to go above and beyond as you work for them already, but you can give them a timeframe for fixes / changes before finally signing it off, you can decide if that timeframe is a year, 6 months, 3 months etc.
If you decide you want to maintain the app, then you can charge them a lower fee and add a maintenance fee on top, but make sure that any timeframe is noted, i.e. once a issue is reported we / i will endeavour to address and fix the issue within 10 days.
If you write these clauses into an EULA of sorts and make sure they understand it as nobody ever reads it, so you might have to reiterate it to them.
Pricewise it's hard to judge as we don't really know what it does, what issue it solves and how much time it saves. You can work out how long it took to write, work out what you would charge as an hourly rate and use that as a baseline figure, if it is similar to another app, then see how much they charge. Is the app server based, i.e multiple users use the same instance or does it have to be installed on many computers? Some companies charge per user.
I could go on, but you get the idea! 
|
|
|
|
|
As others have mentioned, if you sell it to them, it's now going to be on you to support the app. You said your fulltime job is in retail, you're not a fulltime developer - if a significant problem is found and they want you to start working on a fix right away, how's that going to work out with your regular job? Also, expect feature creep.
If you want to avoid this sort of situation, sell it to them for a lump sum, as is, including the source and decent build documentation, so if there's a problem, you're not the only resource they can turn to in order to get something fixed. IF they want you to be the one working on fixes/new features, start billing them separately when these things arise.
|
|
|
|
|
I think it's fantastic when a hobbyist uses their skills to solve a real world problem in their current job. I mean, it's one thing to create a spreadsheet, but an app (of course I don't have any idea what it does) that someone is willing to pay you for is something else. Congrats!  Now you have some decisions to make. Of course it all depends on the money.
If you have any intentions of making money on this app you need to:
0: form an llc - this protects you from personal liability should something go terribly wrong
1: insure your llc for double protection, specifically errors and omissions
2: keep control of your source code!
3: create a EULA - there are samples all over the place. Find one you like and change the names.
As for what to charge, some money up front should be expected, but imho an annual contract is the way to go...recurring revenue are an incentive for you to maintain and improve the app.
Also be prepared for them to ask for exclusive rights. (hint: this is your leverage in the deal) Good luck!
"Go forth into the source" - Neal Morse
modified 26-Jul-19 13:20pm.
|
|
|
|
|
I would make a version that does almost everything necessary, but not quite, and then let them use it on a trial basis. If they like it and want it then they can buy it from you at a price of your choosing and you can add in the lacking feature(s). You can also set a rate of payment for maintenance and enhancements. If you just give it all to them at one go then they will likely never pay you and will probably want changes to be done for free. You hold all the cards so give nothing away!
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
Do some market research. What do similar applications cost?
You need to get paid for your time spent developing that application.
You need to get paid for your time supporting it. Consider a support contract for this part.
You need to get paid a living wage. Don't accept less than you would as a retail employee for the same work, but software developers typically get paid more. Maybe look into the mean compensation for what developers with an equivalent amount of experience get.
Don't sell them the application. Sell them the right to use the application. Make sure you retain rights to sell it to other customers, possibly ones that compete with them, multiplying what you earn for your efforts. Non-competition sales are also done, they cost more, especially if the application would otherwise have value to other customers.
Buying source code to an application usually costs more, so make it clear whether that's included or not (preferably not). If you've already published the source code, take it down now.
Expect that your company is probably expecting to get a bargain on your work. If you can sell it to other companies, you may have to let your employer have it cheap to get your first customer, but then you can charge what it's actually worth to others. This feels wrong, and it feels wrong to be telling you to do this, but you probably won't get a second opportunity like this.
|
|
|
|
|
|
KINK?
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
|
That's a relief because I couldn't justify it: just my brain was goign "K-INK! K-INK!" and I have no idea what it was trying to tell me ... 
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
echo
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
echo
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
echo
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
echo
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
|
PING
entia non sunt multiplicanda praeter necessitatem
|
|
|
|
|
|
I figured out an abbreviated way I think, to compute a k value for a given grammar, without computing the k for every rule.
This is important because it makes lookahead computation for a grammar much more realistic in terms of resources used.
Now, I'm not the only one to come up with an optimization to the general LL(k) algorithm. A lot of people have come up with their own. This is part of mine.
What's interesting here is, if it works, and right now I assume it will, then I will have a viable LL(k) parser.
What's more interesting is the math here. I never got taught formally, but so many people with so many optimizations suggests there's an underlying "better way" to compute all this.
And given all the evolution of the subfield since Wirth, it wouldn't surprise me. As math goes, it moves pretty rapidly in terms of advancement. Over the last several decades the math of parsing has gotten more sophisticated and more realistic at the same time, although the underlying problem domain is unchanged.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
codewitch honey crisis wrote: I figured out an abbreviated way I think
I first read that as you had figured out an abbreviated way to think!
I'm curious, knowing absolutely nothing about your field but read your posts with interest, is there a mathematical way to prove that algorithm is better? Or, probably more importantly, is actually sound?
|
|
|
|
|
yes, but it's above my paygrade. My education is spotty. I was a homeless teen before landing at microsoft at 18 so I never got a formal education in maths.
There are holes in my knowledge. So I can tell you for sure, that yes there's a mathematical way to prove that it works, and to prove that it's "better" (more efficient) but I couldn't tell you what it was beyond maybe some vague notion.
I'm ordering The Dragon Book right now, and hopefully that will help me with some of the math I need.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
You will want to look into Big O Notation - that should be more helpful for analysis of algorithms than the Dragon Book. Wikipedia's entry should get you started.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
i'm familiarish with it. I'm more interested in the hows. I can glean the complexity from that pretty easily.
The problem I've had learning parsing is my lack of formal computer science and math training.
A lot of course material and lecture notes go over my head sometimes, and while the Dragon Book is no different, it's at least the material all of this stuff cites, so if I need to decode something, it may as well be that.
material like this on the other hand: Translating mathematics into code: Examples in Java, Python, Haskell and Racket[^]
has been immensely helpful and I wish there were more of it. Maybe when i've mastered it some myself I'll write an article here expanding on the subject.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
The Dragon Book is a good start on Compilers, but tends to concentrate on LALR parsers. Nonetheless, much of the material will still be helpful. Good luck.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
