So there is an assumption that number of commits means something? I'm just not quite sure what that something is.
What if the software as released is "rock solid"? That is, it's so simple, effective and reliable that it doesn't need to be changed, except for bug fixes?
What if the software is merely a "platform"? (And not only in the marketing sense of that word.) That is, the platform only "does one thing and does it well", and does not generally need to be "actively" developed (no commits except bug fixes), but... of course people can easily build things on top of it. For example, Ruby or Python programmers can do whatever they want. Total freedom. We give them the ability to create a connection to a social network they choose and they can send/receive over it to/from other members as they wish. We do not impose rules on that or try to manage it in anyway. We only provide the platform. The platform is application-agnostic.
The "platform" basically stays the same. It does what it's supposed to do, create networks, and that's all. If we measure by number of commits, one could say the development of the "platform" is "dead".
tl;dr what if someone releases a _platform_ that developers can build on, but number of commits to the _platform_ remains near zero? Because (apart from any bugs found) "it just works."
To my knowledge, Diaspora is closely intertwined with Ruby and web development. This makes it difficult to separate the "platform" from lots and lots of Ruby or other scripting language programming, mainly aimed at webpages, and people changing UI stuff to their liking. And personal preferences can vary greatly. (And there's more to the internet than just webpages. FB has to be webpages because it relies on the web, specifically one person's website: Zuckerberg. Another social network (or newtork of networks) might not be so limited.) Does the dynamic, highly personalised aspect of viewing webpages have to be part of the _platform_? Can we separate the personalisation from the basic functional element of the platform? (spawning decentralised networks)
A project that isn't being actively developed is dead. The idea of a "finished" program that does everything it needs to, one "so simple, effective and reliable that it doesn't need to be changed, except for bug fixes" is an attractive one but it's a myth; there has never been such a program, and I doubt there ever will be.
In fact, most of my kernel is "dead". There is code in there that hasn't been changed in over 30 years!
I'm even communicating over a "dead" protocol. When were the last changes to TCP?
I'd even guess you are using some "dead" software yourself. Low level stuff that no one has the desire nor energy to modify.
(To be clear, I am not suggesting that we should not try to improve programs, continually. I'm only pointing out that perhaps sometimes code works for what it's supposed to do, no one has come forward with something "better" and hence the code does not need to be fiddled with endlessly in the absence of serious bugs.)
Then I hope you have a plan in place for when, not if, they break.
>In fact, most of my kernel is "dead". There is code in there that hasn't been changed in over 30 years!
If the kernel has people who take responsibility for it, and make changes to it, then it's not dead.
>I'm even communicating over a "dead" protocol. When were the last changes to TCP?
The fast open draft was published in July.
>(To be clear, I am not suggesting that we should not try to improve programs, continually. I'm only pointing out that perhaps sometimes code works for what it's supposed to do, no one has come forward with something "better" and hence the code does not need to be fiddled with endlessly in the absence of serious bugs.)
Sure, but I really don't think that's true. Possibly because the lower-level layers are still evolving - code written in low-level languages more than about 10 years ago (before the AMD64 architecture existed) probably won't work correctly on a modern system, and most high level languages have had incompatible changes over the same time period (I know Java's supposed to be an exception to this - allegedly you can still run the original java demos from 1994 on a current JVM). The fact is I've tried and failed to run several programs from >5 years ago, but I've yet to find one that still works without having been maintained.
Still waiting for Ethernet to "break". IP as well. UDP too. And netcat. It's been like 20 years. I'm still waiting.
I also wasn't aware that RFC drafts were the same as "commits".
Originally we were talking about "number of commits". Low number of commits means "dead", so they are say. Are you in agreement with that or not? If so, what does "dead" mean?
Now you are saying if software is maintained (fixing bugs) it's not dead. Who said it was? I certainly didn't. I even went so far as to clarify that.
Let's assume some software is maintained. There's someone to take responsibilty. As you have suggested. But there's no commits, except to fix bugs.
If there's no bugs to fix (maybe one every 15 years), then there's no commits. But if _number of commits_ tells you whether a project is "live" or "dead" then how do you call this a "live" project, if is has almost no commit activity?
My original comment was about the idea of "number of commits"-->"dead" as carrying some deeper meaning, e.g. about the quality of the software.
I like software that works and keeps on working. I really do not care that much if people are committing to it or not. In fact, I'd prefer they didn't because in many cases they only succeed in breaking it or in creating new weaknesses or insecurities.
The original netcat just keeps working. Last "commit" was in the 1990's.
What if the software as released is "rock solid"? That is, it's so simple, effective and reliable that it doesn't need to be changed, except for bug fixes?
What if the software is merely a "platform"? (And not only in the marketing sense of that word.) That is, the platform only "does one thing and does it well", and does not generally need to be "actively" developed (no commits except bug fixes), but... of course people can easily build things on top of it. For example, Ruby or Python programmers can do whatever they want. Total freedom. We give them the ability to create a connection to a social network they choose and they can send/receive over it to/from other members as they wish. We do not impose rules on that or try to manage it in anyway. We only provide the platform. The platform is application-agnostic.
The "platform" basically stays the same. It does what it's supposed to do, create networks, and that's all. If we measure by number of commits, one could say the development of the "platform" is "dead".
tl;dr what if someone releases a _platform_ that developers can build on, but number of commits to the _platform_ remains near zero? Because (apart from any bugs found) "it just works."
To my knowledge, Diaspora is closely intertwined with Ruby and web development. This makes it difficult to separate the "platform" from lots and lots of Ruby or other scripting language programming, mainly aimed at webpages, and people changing UI stuff to their liking. And personal preferences can vary greatly. (And there's more to the internet than just webpages. FB has to be webpages because it relies on the web, specifically one person's website: Zuckerberg. Another social network (or newtork of networks) might not be so limited.) Does the dynamic, highly personalised aspect of viewing webpages have to be part of the _platform_? Can we separate the personalisation from the basic functional element of the platform? (spawning decentralised networks)