Re: REST impact paper
"Stephen D. Williams" <[email protected]>
| Newsgroups | gmane.culture.people.rohit-khare |
|---|---|
| Message-ID | <[email protected]> |
On 9/9/17 2:06 PM, J. Andrew Rogers wrote: >> On Sep 8, 2017, at 10:44 PM, Stephen D. Williams <[email protected]> wrote: >> >> Proprietary code that you can't get to, probably because you can't afford it, doesn't matter. With the cost of commodity hardware, per-core style of pricing may not be competitive with only a 2-5x improvement. > > Unrestricted source licenses to things I would want to license (because they are awesome) are typically an inexpensive one-time cost, usually less than the cost of an engineer to write it poorly. I’ve never seen it structured on a per-core/per-seat basis. It is like forking open source for personal use, occasionally even literally free, except that it is not open source as far as the rest of the world is concerned. Yes, depends on what you're talking about. A lot of software marketed for corporate / enterprise use is per-core, per-system, per-site, and/or per-seat. Just recently I've been pitched some things priced that way. Architecting a company product / service, I think that pricing strategy is a trap: A decade ago I worked with some companies focused on Federal sales that were caught in that pricing model. At least one of them had a very cool product that could have been very popular, but almost no one ever saw it. > As often as not, the “proprietary code” is just code you wrote yourself rather than reusing open source or some other third-party source. It isn’t difficult to justify the effort for systems at scale and the code is reusable going forward. Sure, I do that all the time. I search for open source and commercial options both as possible solutions and to absorb the past and current wisdom in an area. Then I often modify or build. Sometimes, after trying several things, I just write something from scratch. Finding just the right simulation / game scripting solution is just like that. I looked at and sampled many things; everything remotely related I think. I already have a license for the best commercial solution, but the C++->JS gap (Emscripten of course, then adapting), and the mismatch of models, has that on hold as the backup option. Now I have a secure, concise, and sophisticated solution, but it was a winding road of almost. I have ambitious constraints ("implicit concurrency", security, conciseness, power, efficiency, portability), so it isn't as straightforward as you would think. The result will be very nice. > Andrew sdw _______________________________________________ FoRK mailing list http://xent.com/mailman/listinfo/fork