4 ms·
On a tangential note, I wonder if this says something about the way in which open source is delivered in a github world? Some of the best parts of open source w
by nstart 10y ago
On a tangential note, I wonder if this says something about the way in which open source is delivered in a github world? Some of the best parts of open source was the flexibility. Someone isn't maintaining a project you want? Maintain it yourself. Or switch to something that's being maintained by someone else.
This is a rather abstract thought so I apologise in advance for it. I'm wondering what an open source world/tool that embraced that fluidity might mean for end users and core maintainers. Assume a tool called gitworld existed that did this. It might look like something where you can see which forks are best maintained. Community discussions can happen around all the forks as opposed to being against a repo by repo basis. So issues and PR's created could be applied by default to all forks and we might see which forks have closed these off? If I open an issue and a maintainer fixes it on her fork, the issue would show me that it's closed there and the final build exists there. It might also be really neat to have builds that become portable across forks so when someone forks my repo, as they work on it their code gets built and packaged automatically if I've done the necessary work to set those up. (not a very practical idea given resource constraints but it would be neat).
Like I said, it's an abstract thought but given the trend that we are seeing in open source management challenges, I'm wondering if it's time for a paradigm shift as it were in managing open source projects, communities, and expectations.
- gaxun 10y agoI have posted a couple things related to this but never finished a complete summary of my thoughts. These two attempts come close: In [0], I shared some really basic thoughts about how this could be done by users of a particular VCS package, git. Two line summary: You run `git announce [name] [tracker]` to tell a git tracker that you've got your own fork. If you host your repository in a public place, the tracker just checks your repo for updates so other users can stay informed. At [1], I describe a similar system with a specific type of frequently-forked software (GPL'd tools). This seems less tied to using git. This software is available from diverse sources in multiple VCS systems and may be wildly divergent. Comparing the sources seems valuable, but difficult. Alternatively, Fossil does "distributed version control and issues", but it's really just meant to be one central location for a particular project. Thought I'd share. I'm on board with everything you're saying. There are clearly some issues as well, though. The biggest one I see is related to the "paradox of choice" -- when there are four forks all just one commit different from each other, how do you know which one(s) to use? This is why we usually just follow the leader (maintainer) and use the one true source. End users don't have the ability to quickly know which patches to accept and reject. Even a reputation system wouldn't necessarily provide clean signals, due to bandwagon type effects. Unfortunately, I already have enough trouble picking between `iron` and `nickel` as a Rust web framework. [0]: https://www.gaxun.net/ideas/git-announce/ https://www.gaxun.net/ideas/git-announce/ [1]: https://news.ycombinator.com/item?id=13028079 https://news.ycombinator.com/item?id=13028079
- perfmode 10y agoI like where you're going with that. I would love to see some innovation in this space.