> A web UI ensures everyone has a great user experience right out of the gate.
That may be true for you, but it's in no way as universal as you seem to think.
I have a productive workflow (that gives me enough free time to comment on HN :-) that is effective for the several things I work on during the day (a couple of development projects, some management, etc). Hopping over to some web silo doesn't speed things up for me.
The real reason people stick to the current model is because it works. A common baseline lets people use the tools that work for them rather than trying to cram everyone into the same procrustean tools space.
Yeah, I realize a lot of devs have already have their own setups that work extremely well for them. Unfortunately anytime you transition to a new tool you're obviously going to break _someone's_ workflow.
That said, switching to something like GitHub doesn't necessarily mean developers all _have_ to use exactly the same workflow. For example, if you're more comfortable in the command line, there are tools like [hub][1] and [git-gitlab][2] available which let you perform common tasks in GitHub/GitLab using the CLI.
I just think that long-term it's better to have a good baseline user experience that devs can then extend with their own personal tools if they choose than to have a not-so-great one that _requires_ you to extend it with your own tools before it's anywhere near as good as what a well-designed Web UI provides out-of-the-box; even if in the short-term that means breaking some dev's workflows.
Obviously that doesn't mean you shouldn't try to maintain compatibility with developer's existing workflows wherever possible though. For example, GitLab and GitHub both let you reply to issues by email, and RocketChat has an IRC plugin that lets you connect RocketChat rooms to an IRC channel.
I feel like you're addressing a nonissue. If you want to start your own project, you can set the standards for development process, coding standards, language, etc. If I don't like those choices it's no big deal and no slur on you: I'll just work on what I want and folks who agree will be delighted to work with you.
But your note feels like you're saying "why don't the kernel dev switch to Ruby?" Of course when I say it that way it sounds absurd, but really it's simply an equivalent.
By that reasoning though, isn't almost every problem in open source projects a "non-issue", because you can always just fork and do things your way?
The point is that reducing the friction required to contribute to an open source project is a great way to attract new contributors. Using more user-friendly dev tools is a great way to do that, and is therefore something existing maintainers would be wise to consider doing.
> By that reasoning though, isn't almost every problem in open source projects a "non-issue", because you can always just fork and do things your way?
Yes. Because that's true. Either you have a good point and manage to convince people in the project, or you have to fork.
Writing irrelevant comments on some news site is not going to convince anyone to spend a combined hundreds to thousands of man-hours work (at the very least) to move kernel development to GitHub or whatever platform you like.
Also notice how you are ranting about tooling in a project you're not contributing to, while the submission here is about something entirely different -- and written by a contributor.
> Writing irrelevant comments on some news site is not going to convince anyone to spend a combined hundreds to thousands of man-hours work (at the very least) to move kernel development to GitHub or whatever platform you like.
So you're saying we shouldn't discuss this at all? Just shut up and stop trying to convince anyone to adopt a viewpoint I believe would be beneficial to open source projects in the future?
IMO open discussions like this are a good and healthy thing for any community of developers (such as the one on Hacker News) to have. It's a great way to share ideas with each other and collectively come up with ways to improve the open source community. It's not something that should be discouraged.
> Yeah, I realize a lot of devs have already have their own setups that work extremely well for them. Unfortunately anytime you transition to a new tool you're obviously going to break _someone's_ workflow.
So don't.
Do you have a single compelling issue why they should switch?
Yes. All of the benefits I mentioned in my previous posts further up in this thread. It all essentially boils down to making it as easy as possible for new potential contributors to contribute.
New potential contributors to a kernel that are deterred by not having a ruby-on-rails web GUI wouldn't have contributed anything anyway. (IOW there are none that fit you description).
That may be true for you, but it's in no way as universal as you seem to think.
I have a productive workflow (that gives me enough free time to comment on HN :-) that is effective for the several things I work on during the day (a couple of development projects, some management, etc). Hopping over to some web silo doesn't speed things up for me.
The real reason people stick to the current model is because it works. A common baseline lets people use the tools that work for them rather than trying to cram everyone into the same procrustean tools space.