twelve45
Also, "Why is it free?" is another way of asking "What's the catch?". It's important to understand this before you put in a bunch of work...
However, whatever your views on closed source products, they are still quite prevalent. IMO LGPL is a great license to get support from companies that sell these products, while ensuring that your software fundamentally remains free.
Unlike other OSS licenses like BSD, Apache, LGPL, etc, GPL makes it impossible to utilize the library in any way in a commercial product. My current company works on some video related stuff, and we use OpenCV, ffmpeg etc but we completely steered clear of libVLC due to the GPL licensing (even though we think it's a fantastic piece of software). We will however be revisiting this now due to this excellent work by jbk.
To echo tinco's comment, do not try to explain the intricacies of what you're doing to your customers. Put yourself in their shoes and think about what is important to them. Explain just the "end results" of your tooling, emphasizing the points that are important to them and leaving out everything else.
For example, you could say that the caching rework will improve the performance of the system, software-defined infrastructure will ensure minimal downtime in case there's a hardware failure, etc. These are all benefits your customers will understand, even though they may not care or understand how exactly you will achieve them.
It is incredibly important to get your tools right so you can operate as efficiently as possible. At my company we didn't get around to this till much later, partly due to the dilemma you mentioned abt focusing on customer-facing software vs. internal tools, and partly due to the fact that the people who would benefit the most from automation (e.g. finance folks, inventory managers, etc) don't have the same obsession with automating away mundane tasks like us engineers do.
This lack of tools hurt us quite a bit once we started scaling, in ways that impacted some customer relationships (because occasionally we didn't invoice or ship correctly, etc). We have since invested significantly in tools, but we should've done this to begin with.
To make the customer vs. internal tools compromise easier, you may even want to get some basic tools in place via contract work/offshoring and then revisit these later once you have the time/resources. The hard part really is determining what to automate, and how much, and those are decisions that you should make. The development itself can be done by someone else.
To add to your morale point, I look at tech blog coverage as great for recruiting engineers, as that's where engineers tend to hang out to find the next "hot" company (vs. websites specific to your vertical, where your customers hang out).
For example, I've personally realized that management is not really my thing, but having done it for a while I understand better now where my ex-managers were coming from and feel that I'm now a better employee because of that. Same for design work, etc.
And frankly I wish other people did that too. Wouldn't it be great if your manager understood your explanation of why that "tiny" feature will actually take weeks, or the designer keeps potential code complexity in mind when designing something? I think this advice applies to everyone, not just programmers.
When you reserve an instance, you are committing to a higher upfront in order to get a lower hourly for the reservation period. The low/medium/high utilization is sort of a knob that allows you to further control this upfront vs. hourly cost. With high utilization you have the highest upfront, but also the lowest hourly cost. If you are planning to run the server 24x7, this will also give you the lowest total cost.
This is certainly the case with their new "Uber X" service as well that got into trouble in DC - the only difference is that they dispatch hybrids from their partners vs. towncars / SUVs.
Forward many years, and I have my own thing going and I appreciate the failed startup experience because it gives me some framework on which to base my decisions. And I hope I'm doing things better... (and that a few years from now that junior dev we just hired will do a better job with his/her company!)
I'd consider this similar to how he was said to have very good taste in design, even though he may not have been able to design things all by himself.
RetailNEXT (http://bviretailnext.com)
We are google analytics for the real-world. We use a combination of machine vision (OpenCV + our own algorithms) on standard video cameras, and other inputs like RFID/WiFi data to build a complete picture of what's happening inside a physical retail store. No cookies or IPs to play with in the real-world, so a much harder (and hence much more interesting!) problem.
Each month we track nearly 2M people worldwide across our several retail customers (a few are listed on our website). We are fundamentally changing the way retail stores are designed and operated.
We use C/C++, Java, Python and Flex. Our product runs on Linux. We like super-smart generalist hackers who are into machine vision, data visualization, AI or data mining/big data analytics. Interested? Drop us a note at [email protected].
Most recruiters have no clue how to find "smart developers". So instead they do a google search for "Java developer looking for job" and spam you with the top 10 hits with some great insights like "OMG this guy's great... he's only done Java for the last 20 years!!!1!". They don't understand why that's NOT a good thing in tech.
If you run an e-commerce website, you probably use google analytics, mixpanel or similar to track your customers and do some funnel analysis, A/B testing etc to optimize your site.
If you run a physical retail store though, you're out of luck. How many people walk into my store and leave frustrated, without buying anything? Why isn't my hot new item selling - is no one seeing it, or are they seeing it but not buying because the price is too high? There's no easy way to find answers to these today.
Not having cookies or IPs makes tracking in the real-world a real challenge! We primarily acquire data through machine vision algorithms that run against video cameras in the stores and identify and track people, but we also use data from a host of other technologies (RFID, WiFi, Zigbee, etc) to get the full picture.
We just closed our series B, and are scaling very fast. We use C/C++, Java, Python and Flex. Our product runs on Linux. We like super-smart generalist hackers who like working on a variety of things - UI development, machine vision algorithms, AI, data mining/analytics on big data (last month we tracked nearly 2M people worldwide!). Hit us up at [email protected].