1) Make your software code clean
2) Agree with your manager/HR/Legal dept to release it as free and open-source (that's right)
3) Wait for other developers to use your software
4) Make your own company and get paid for the support
If your software is worth something, you'll be fine.
If not, but still it becomes rather popular, you can put it in your resume and keep selling yourself.
...given its mindset begins that early.
"It is hoped that all parties can work in concert to address hacker attacks in a positive and constructive manner."
...all parties? I thought there was just one.
Finally! strI wWas rReally uMissing szSome Hungarian pNotation!
Thank you, I think you're right.
My comments above were probably due mainly to ignorance.
After all I've never bothered looking at that code before and should have studied the whole thing before judging... well... the whole thing.
Maybe it's off-topic, but is it just me who see potentially big problems with ed25519.c? e.g. http://bxr.su/OpenBSD/usr.bin/ssh/ed25519.c#25
Hint: no input validation, hard-coded array offsets with no clue about their expected size, etc...
I know, it's open-source (I should contribute, blablabla) but I see this kind of problems all over that code base.
How so? TrueCrypt is neither Open Source or Free Software. It's freeware (ie. proprietary).
Right, TrueCrypt is not "Open Source", it's "open-source".
...He didn't mention how to choose an appropriate software license!
That's definitely something that impacts the popularity of any open-source project.
A 'git push' every now and then may help* in these cases...
* (both you and the other guys working on your project)
Design patterns led to "programming by buzzword". And perhaps as bad, interviewing by buzzword, so people who could recite pattern names by rote would get hired.
Although this may be OT, I do ask design patterns to my interviewees. However it's not like "tell me what a Visitor is", rather "you have this problem, how would you solve it?". The good ones come up with several solutions, some of which resemble (or exactly overlap with) a design pattern, and that's enough. If they are also aware of this, it's a bonus.
Said that, the value of patterns is not just in using them (they originate from common sense after all) but also in creating a common ground for communication and practice: if you see a class named "Observer" or "Factory" you should immediately imagine what it is about. Presentation patterns could have similar benefits, e.g. an organisation may decide to deliver all presentations in a certain format.
There's nothing new in this, just a few examples: the 10/20/30 rule and pecha-kucha (pronounced like this).
"Engineering without management is art." -- Jeff Johnson
