21–30 of 33 posts
OSS has basically theseus shiped into something completely different. Not a criticism just an observation.
Every time I see some post where commits are taken as contribution metrics, I remember when, after working for months at it, I merged Redis Cluster into Redis as a single commit, and saw the pale green square appearing for that day in my GitHub contributions chart. Now it's 1.5 months that I work 10h/day at Redis Vector Sets and they will also be a single commit. It's very simple to do better than that, as a metric:…
I think the authors agree with you. They tried to look at lines of code added / deleted (eg "they consistently made over 95% of the lines added to and deleted from Elasticsearch") - although the language in the article flops between that and just saying 'commits', so it's not sure what they were actually looking at for the write up. In their scraping code / dataset linked at the start of the article, they are logging…
Earlier quoted context omitted.
> That's why forking is uncommon in open-source code, and even more so in (specifically) GPLed code: The improvements one group makes in its would-be "fork" are freely available to the main community. Unfortunately, in the smartphone world this just isn't reality. Trying to obtain code dumps is hard enough for major brands, outright impossible for the myriad of cheap clones. And embedded is even worse, almost no one…
> The improvements one group makes in its would-be "fork" are freely available to the main community. IANAL, but there's a caveat here, which is that a lot of these forks are due to companies relicensing to source-available licenses, which generally means they require a CLA (and full copyright license) from each of their contributors, so that they can relicense the codebase at will. The code committed to the fork can…
I understand that the companies probably did majority of the work, However I can't put my finger on this comparison... Sounds strange and inaccurate
As with many more modern "Open source" projects, the openness is more of a "You can try for free, and once you need production level SLA come call us". While the source code is available to look at it's more of a facade as almost no one change it but the owning company. Limited by complexity of the project, maintainer politics and IP around supporting tools and materials. OSS has basically theseus shiped into somethi…
The more open the license, the more options available.
Earlier quoted context omitted.
I think the authors agree with you. They tried to look at lines of code added / deleted (eg "they consistently made over 95% of the lines added to and deleted from Elasticsearch") - although the language in the article flops between that and just saying 'commits', so it's not sure what they were actually looking at for the write up. In their scraping code / dataset linked at the start of the article, they are logging…
The data about Redis can be true only if they mean "commits". This is why I believe they checked Github contributions numbers.
I am quite curious as to your take on a few metrics that would help evaluate the health of a code base. It's a dirty job, but we all have to do it every time we look for something new.
Related: "Fear of Forking" by Rick Moen http://linuxmafia.com/faq/Licensing_and_Law/forking.html
> That's why forking is uncommon in open-source code, and even more so in (specifically) GPLed code: The improvements one group makes in its would-be "fork" are freely available to the main community. Unfortunately, in the smartphone world this just isn't reality. Trying to obtain code dumps is hard enough for major brands, outright impossible for the myriad of cheap clones. And embedded is even worse, almost no one…
Most problem of BSP programming is it is really complicated, because need to fit within limits of hardware and need to have deep knowledge of DSP environment.
So it is very interest question, who will do complicated things for free, or who will dive deep for free.
Unfortunately, too many people compare apples with carrots, in this case compare definitively shallow frontend/full-stack programming vs hardcore embedded.
And returning to question, in real life, nobody want to rewrite all core code for BSP, but really use huge chunks of ready made code, provided by vendor, so, sure they have very tight coupling to vendor copyrights.
Sometimes, things are even worse with hardware limitations, which just made impossible to write other way than does vendor.
Other problem, regulations - using vendor code you automatically obey laws, or to be honest, you shift responsibility to vendor, but if write your own code from scratch, will need someway create proof that people could trust to your code.
As with many more modern "Open source" projects, the openness is more of a "You can try for free, and once you need production level SLA come call us". While the source code is available to look at it's more of a facade as almost no one change it but the owning company. Limited by complexity of the project, maintainer politics and IP around supporting tools and materials. OSS has basically theseus shiped into somethi…
One key element often overlooked but mentioned in the recent post from Fusion Auth is the Business Continuity aspect. If your provider suddenly shuts down but the product was open source and self hostable, you can pay someone else to keep it working while you work on a migration plan on your own timeline. The more open the license, the more options available.
Why would a company ever open-source their product then? Giving up that complete leverage can be a selling point during the purchasing process, making buyers more comfortable that they won't be (completely) locked in, and be a net positive on revenue through faster sales.
Earlier quoted context omitted.
> That's why forking is uncommon in open-source code, and even more so in (specifically) GPLed code: The improvements one group makes in its would-be "fork" are freely available to the main community. Unfortunately, in the smartphone world this just isn't reality. Trying to obtain code dumps is hard enough for major brands, outright impossible for the myriad of cheap clones. And embedded is even worse, almost no one…
> Trying to obtain code dumps is hard enough for major brands, outright impossible for the myriad of cheap clones. And embedded is even worse, almost no one cares about distributing the GPL code of the BSP, mainly due to fear of violating chipset vendor NDAs. Sounds like an opportunity for the copyright holders to make some money by suing and dual licensing.
Every time I see some post where commits are taken as contribution metrics, I remember when, after working for months at it, I merged Redis Cluster into Redis as a single commit, and saw the pale green square appearing for that day in my GitHub contributions chart. Now it's 1.5 months that I work 10h/day at Redis Vector Sets and they will also be a single commit. It's very simple to do better than that, as a metric:…
Said company was bought by a large US company where one of their key metrics for a developer was number of new lines of code.
It went down-hill from there. 10% of people were fired because mothership instituted job cuts globally, and then people were leaving, then another round of cuts, then most people left, then the company was sold, I think losing a fairly hefty part of its valuation.
Eventually large US company was bought by Oracle, which to my eye indicated Oracle is like MS; they have a single product, which is a massive cash cow, and for the rest, they serially make terrible decisions (a la Nokia et al).