4 ms·

This is a very good point that has been proven over and over again in the industry. I recall being at Sun and having the argument over ONC and whether or not it

This is a very good point that has been proven over and over again in the industry. I recall being at Sun and having the argument over ONC and whether or not it should be "open" (which at the time meant everyone could get a copy of the code[1]) or "closed". Ed Zander was a big fan of keeping everything secret, after all anyone could reproduce it if they had the code right? And I used the same argument as the author, which is that if someone was a decent programmer and willing to invest the time, they could recreate it from scratch without the code so keeping the code secret merely slowed them down fractionally but letting our licensees read the code allowed them to better understand what worked and why and could release products that used it faster, which would contribute to its success in the marketplace. I lost that battle and ONC+ was locked behind the wall until Open Solaris 20 years later. So many people in tech cannot (or perhaps will not) distinguish between "value" and "cost". Its like people who confuse "wealth" and "money". Closely related topics that are fundamentally talking about different things. This is why you invest in people and expertise, not tools. Anyone can learn a new toolset, but only the people with expertise can create things of value. [1] So still licensed, but you couldn't use the trademark if you didn't license it and of course there was no 'warranty' because of course the trademark required an interoperability test.

RajT88 1y ago
There is a feeling that releasing the code is "giving it away for free". But, being able to compile and deploy it is not the whole story. Enterprises need support from the people who built the thing, and so without that it is not a very attractive proposition. It could be true in some scenarios though. Microsoft doesn't open source Windows. A big enough company could fork it and offer enterprise support at a fraction of the cost. It would take them years to get there, and probably would be subpar to what large Windows customers get in support from Microsoft. Yes I know y'all hate dealing with Microsoft support - imagine that but worse. Still, the company with the forked distro would definitely take a bite out of Microsoft's Windows business, if only a small one.
- ChuckMcM 1y ago
  > Still, the company with the forked distro would definitely take a bite out of Microsoft's Windows business, if only a small one. That has not been shown to be the case. There is ample evidence that other companies would run this 'off market' or 'pirate' version, and zero evidence that if those choices had been unavailable that they would have legitimately licensed Windows. You are making a variant on the 'piracy losses' argument which has been shown is simply a pricing issue. If you "ask" for more than your product is "valued" then it won't be purchased but it may be stolen. And if you make it "impossible" to steal you will reduce its value to legitimate customers and have zero gain in revenue from those who had stolen it before (they still won't buy it). The "value" in Windows is the number of things that run on it and the fact that compatibility issues are "bugs" which get fixed by the supplier. We are rapidly reaching the point where it will add value to have an operating system for AMD64 hardware that is overtly governed (not Linux or FOSS) which allows you to get a copy of the source when you license it, and has an application binary interface (ABI) that other software developers can count on to exist, not change out from under them, and last for 10+ years. As Microsoft (and Apple) add more and more spurious features which enrich themselves and enrage their users the "value" becomes less and less. That calculus will flip and when it does enterprises will switch to the new operating system that is just an operating system and not a malware delivery platform.
  - antihipocrat 1y ago
    >>have an operating system for AMD64 hardware that is overtly governed (not Linux or FOSS) Not understanding this part, aren't Linux distros achieving this already without licence restrictions and various levels of stability depending on the distro selected? A huge amount of enterprise tooling is now being run on the cloud through the browser or via electron - for a large number of businesses, their staff would only need the equivalent of a Chromebook style GUI to perform their work. Native software is still essential for a small % of users.. is this what you're suggesting needs to be solved? A single alternative open source system (OS or VM?) that the software dev company can target.
    - ChuckMcM 1y ago
dmurray 1y ago
> if someone was a decent programmer and willing to invest the time, they could recreate it from scratch without the code This is a stronger claim than the one in the article, which says it's easy for someone to recreate it if they were involved in building it in the first place. It's not true that every piece of software is trivial to copy in a clean-room way, that is, only being able to observe its behaviour and not any implementation details.
- jvanderbot 1y ago
  Somehow people are reading a strange, opposite conclusion from this headline. See the "30m to reproduce a days work" argument. What TFA says is that the writing of the code is not the most valuable part of this process, but that does not mean that the code itself is of little value. The fact that writing the code is "easy" once the solution is found does not mean code is of little value! This article shows that code is extremely valuable since it codefies exactly the business logic, design, and hard work of problem solving. It's the map leading through all the challenges to a business solution. It's a shortcut and a working tool. It's the whole point of having expensive software engineers doing difficult design work. Your clean room argument is spot on.
  - 6510 1y ago
    Thinking about it, the encoded business logic also becomes hard to change. Perhaps like writing prevented language and stories from evolving. Encoding it might be the final version. I got stuck a few times when the business logic got overly fuzzy. If you have 10 people and 50 small tasks with each task taking between a and b minutes in some strange distribution where b might be 3xa. If task 1 takes more than c minutes task 2 is likely to also take longer while task 3 will be easy. Unless it is full moon then task 2 will take less time and 3 more. On the factory floor the guy to plan this would also know how fast each employee is with each task and that employee 1 has a hangover on Monday, 2 goes to the gym on Thursday and 3 has to babysit before the night shift. But now we are going to have an app to plan this???
- ChuckMcM 1y ago
  > It's not true that every piece of software is trivial to copy in a clean-room way, that is, only being able to observe its behaviour and not any implementation details. Ideally, you can change the way you look at this slightly. We can agree that software isn't "trivial" to create. You limit your claim 'observing its behaviour' however and that isn't as precise as we'd like. I'd make the claim this way: "Any piece of software, for which you have both the requirements that define its use and a working example that putatively meets those requirements, is straight forward to re-create from first principles." It is the very definition of the job description that a programmer/engineer can take "requirements" and turn them into "product." That doesn't say anything about how easy or hard that is, just that its the job and people do it all the time. When you have a working example, it both facilitates the engineer's understanding through observation, and provides a test by which the engineer can measure their own progress in meeting the requirements. That allows for iterative development which happens, in my experience, more quickly than when there is not a working example to compare against.

RajT88 1y ago

There is a feeling that releasing the code is "giving it away for free". But, being able to compile and deploy it is not the whole story. Enterprises need support from the people who built the thing, and so without that it is not a very attractive proposition. It could be true in some scenarios though. Microsoft doesn't open source Windows. A big enough company could fork it and offer enterprise support at a fraction of the cost. It would take them years to get there, and probably would be subpar to what large Windows customers get in support from Microsoft. Yes I know y'all hate dealing with Microsoft support - imagine that but worse. Still, the company with the forked distro would definitely take a bite out of Microsoft's Windows business, if only a small one.

ChuckMcM 1y ago
> Still, the company with the forked distro would definitely take a bite out of Microsoft's Windows business, if only a small one. That has not been shown to be the case. There is ample evidence that other companies would run this 'off market' or 'pirate' version, and zero evidence that if those choices had been unavailable that they would have legitimately licensed Windows. You are making a variant on the 'piracy losses' argument which has been shown is simply a pricing issue. If you "ask" for more than your product is "valued" then it won't be purchased but it may be stolen. And if you make it "impossible" to steal you will reduce its value to legitimate customers and have zero gain in revenue from those who had stolen it before (they still won't buy it). The "value" in Windows is the number of things that run on it and the fact that compatibility issues are "bugs" which get fixed by the supplier. We are rapidly reaching the point where it will add value to have an operating system for AMD64 hardware that is overtly governed (not Linux or FOSS) which allows you to get a copy of the source when you license it, and has an application binary interface (ABI) that other software developers can count on to exist, not change out from under them, and last for 10+ years. As Microsoft (and Apple) add more and more spurious features which enrich themselves and enrage their users the "value" becomes less and less. That calculus will flip and when it does enterprises will switch to the new operating system that is just an operating system and not a malware delivery platform.
- antihipocrat 1y ago
  >>have an operating system for AMD64 hardware that is overtly governed (not Linux or FOSS) Not understanding this part, aren't Linux distros achieving this already without licence restrictions and various levels of stability depending on the distro selected? A huge amount of enterprise tooling is now being run on the cloud through the browser or via electron - for a large number of businesses, their staff would only need the equivalent of a Chromebook style GUI to perform their work. Native software is still essential for a small % of users.. is this what you're suggesting needs to be solved? A single alternative open source system (OS or VM?) that the software dev company can target.
  - ChuckMcM 1y ago

dmurray 1y ago

> if someone was a decent programmer and willing to invest the time, they could recreate it from scratch without the code This is a stronger claim than the one in the article, which says it's easy for someone to recreate it if they were involved in building it in the first place. It's not true that every piece of software is trivial to copy in a clean-room way, that is, only being able to observe its behaviour and not any implementation details.

jvanderbot 1y ago
Somehow people are reading a strange, opposite conclusion from this headline. See the "30m to reproduce a days work" argument. What TFA says is that the writing of the code is not the most valuable part of this process, but that does not mean that the code itself is of little value. The fact that writing the code is "easy" once the solution is found does not mean code is of little value! This article shows that code is extremely valuable since it codefies exactly the business logic, design, and hard work of problem solving. It's the map leading through all the challenges to a business solution. It's a shortcut and a working tool. It's the whole point of having expensive software engineers doing difficult design work. Your clean room argument is spot on.
- 6510 1y ago
  Thinking about it, the encoded business logic also becomes hard to change. Perhaps like writing prevented language and stories from evolving. Encoding it might be the final version. I got stuck a few times when the business logic got overly fuzzy. If you have 10 people and 50 small tasks with each task taking between a and b minutes in some strange distribution where b might be 3xa. If task 1 takes more than c minutes task 2 is likely to also take longer while task 3 will be easy. Unless it is full moon then task 2 will take less time and 3 more. On the factory floor the guy to plan this would also know how fast each employee is with each task and that employee 1 has a hangover on Monday, 2 goes to the gym on Thursday and 3 has to babysit before the night shift. But now we are going to have an app to plan this???
ChuckMcM 1y ago
> It's not true that every piece of software is trivial to copy in a clean-room way, that is, only being able to observe its behaviour and not any implementation details. Ideally, you can change the way you look at this slightly. We can agree that software isn't "trivial" to create. You limit your claim 'observing its behaviour' however and that isn't as precise as we'd like. I'd make the claim this way: "Any piece of software, for which you have both the requirements that define its use and a working example that putatively meets those requirements, is straight forward to re-create from first principles." It is the very definition of the job description that a programmer/engineer can take "requirements" and turn them into "product." That doesn't say anything about how easy or hard that is, just that its the job and people do it all the time. When you have a working example, it both facilitates the engineer's understanding through observation, and provides a test by which the engineer can measure their own progress in meeting the requirements. That allows for iterative development which happens, in my experience, more quickly than when there is not a working example to compare against.