3 ms·

Open source is an implementation strategy for closing a business model. Strategic use of open source can move a business model from a money loser to a money mak

• hda111 6y ago
  I don’t agree with reduced maintenance cost because all internal patches must be ported to newer versions of the component all the time.
  • hansvm 6y ago
    It's quite possible for that workload to still be cheap relative to writing it yourself from scratch (e.g., I wouldn't think twice about vendoring git-subrepo). That said, if incorporating upstream changes is more expensive than writing it yourself then...just fork the project and write new changes yourself. It's definitely possible that the project isn't a good fit and that you'd be better off starting from scratch than starting from an open-source base, but that dimension is orthogonal to the question of ongoing maintenance cost.
  • mch82 6y ago
    The concern you raise is a valid & important to consider. I’ve seen situations where there’s a mismatch between the update schedule of a component and the update schedule of the larger project & it creates an issue.
• ChrisMarshallNY 6y ago
  > if one is needed at all Depends. If what we are releasing is a product of engineering (even someone else's), we'll need someone that at least thinks like an engineer in the woodpile. In my experience, engineering isn't really about balancing binary trees, designing FFT implementations, or writing functional code. I believe that it's a discipline, and an approach to an organized, end-product-oriented, problem-solving way of working. I've met people that I'd definitely classify as "engineers," that have jobs with no obvious connection to tech, like soldiers, masons, carpenters, and even janitors. I've also met people with advanced technical degrees that can't take an engineering approach to save their lives. Their code and products have been abysmal failures. As long as I've been in tech, there's been this myth of the "engineer-free" product. The one that is dreamed and executed by Corner-Office executives. A product that jumps straight from their genius, into customers' hands; with none of those messy tecchies fouling the mix. Maybe, one day, it will become a reality, but I haven't seen anything that even comes close. I believe that the current "dependency-first" development model is not actually a bad one, but it is one that can go horribly, horribly pear-shaped, if done without a disciplined, deliverable-focused, engineering approach. For myself, I've always enjoyed doing open-source. It gives me a nice track record to which I can refer, and it has forced me to do top-quality code. We always clean the place before we do an open house. If we do it often enough, it becomes habit. I'm currently working on a closed-source app, but that has little to do with IP or security, and more to do with a marketing embargo. I look forward to open-sourcing it in the future. Significant parts of it are already open-source (almost all written by Your Truly). It isn't really meant to be a profit-making app, but it certainly knocks a lot of commercial apps into a cocked hat; and it's only half-done. Not a guarantee of quality, but it does work for me. I think that Atlassian open-sources all of their stuff. They seem to be doing OK (I am not a huge fan of their stuff, but can't argue with their success).
• ankmathur96 6y ago
  Your point about commoditizing an existing market segment is extremely underrated. Companies should use open source where the existing solutions are blackbox but also commoditized. If everyone's doing it but keeping their doors closed, you have a chance to create an open standard. If it's successful, all the black box companies have to adapt it and basically have now wasted a bunch of time