The GIMP project learned this the hard way: http://www.gimp.org/news/2015/05/27/gimp-projects-official-s...
Since they used to be the official source, their repository tend to have very high PageRank and they're essentially cashing in on it. Since the content they host is open-source, this is technically legal, but it's scummy as all hell.
This was a BlackBerry project, though, and it wasn't something you could install on a desktop - that may have been a contributing factor, but I never had any problems with them continuing to host the content after I deleted it.
If the project is licensed under GPLv3 (or any other strong copyleft license), wouldn't they be illegally hosting it because they are bundling their malware dropper with software that isn't compatible with the license?
> The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources.
Same with the Debian Free Software Guidelines [1]:
> The license of a Debian component may not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources.
In reality though there's a reason there are many different OSS licenses - many devs want options around attribution and yes, around use in limited ways. A please don't use this for abject evil clause may not meet the no true open source dictionary definition, but pragmatically speaking it's not necessarily a terrible idea.
(The forum is a front-end to the mailing lists / newsgroups.)
Instead, it's all either slow, slow backend frameworks like Ruby, or even worse, these SPA applications that require extensive client-side JS processing before they show you the goods.
Node is a step in the right direction for both problems: for the first, Node-based backend applications are faster than Ruby and Python, and for the client-side rendering problem, because Node can pre-render these SPA apps (which everyone should do for a serious production app that uses a framework/library like AngularJS or React for major client-side rendering).
But a server application based on D or Rust, or even Go, is an even better solution to the slow backend framework issue. Unfortunately, no one has yet created a full-service framework like Rails or Django for any of those languages.
Usually this is a matter of bad coding or overprovisioning of whatever is being used to host the site and the DB. Most maintained languages running on modern hardware can sustain reasonable loads without any significant performance issues. While client-side bad-performing frameworks abound, the last I looked into it, Ruby+Rails isn't that much worse or better than any other.
Very nice.
The source code running it - https://github.com/CyberShadow/DFeed
Hi. I'm from the Discourse team, and I recently "soft-pitched" an idea that seems very much in line with what you're looking for.
https://meta.discourse.org/t/becoming-the-new-standard-discu...
Regardless of the above, we're gonna be doing a significant push for better mailing list features during the months to come, so any feedback you or any other open source projects may have, please nudge me on meta.discourse.org or send me an e-mail (my first name, erlend, at the company domain).
Uggh ... really ?
So the simple, clean, extremely fast loading HTML indexes of mailman/majordomo[1] aren't going to do it for you anymore ?
Yes, I was getting so tired of one click getting me to a nice, clean index, ordered by year and month, and loading near-instantly. What a pain that's always been.
Get. Off. My. Lawn.
I'm not suggesting the existing software to change, I'm suggesting something new. Pitching something that doesn't exist today (the D-Lang forums linked here come quite close though). Our goal is to merge our current forums with our mailing list and not have to maintain both separately.
So I'll thank you to get off my damn lawn, you and the seven crates of entitlement you carry around.
I design user interfaces and creating a new UI for basically what mailman does would really just be an attempt at grabbing a different target audience.
mailman has an image behind it. People associate with different images, and certain looks and feels make certain people gravitate towards them.
The type of people I would want in my mailing list are the type of people that appreciate how mailman looks as-is.
I try to practice great design where it matters most. A reskin of such software would be more aligned with the goals of junior designers and people who rehash weather apps with nice gradients on dribbble.
> "User needs"
Do you actually design anything?
Really dangerous.
"It is a place for FOSS communities to discuss all the things they want without ads, censorship, signup requirements, bundled apps, or requirements that you use any particular email client or service."
My project is using Google Groups just fine. Do not list your group in public directory to prevent spam.
Redis is moving from mailing list to Reddit. That seems to work for them.
At this point, unlike Reader, there's real cash behind the functionality. It's possible they could just fold it into Gmail, I guess, but with other mail interfaces like Inbox popping up in the Google ecosystem it seems if anything they're trying not to shoehorn too much more into a flagship product.
My guess is Groups will stick around for a while yet.
So it’s possible.
IMHO a publicly/semi-publicly logged irc channel would do just as well, but that's even more oldschool.
As for Discourse's mockery of a mailing list mode, let's not even talk about it.
GitHub has email notifications for issues, but you can opt out of any particular discussion if it gets too pedantic or doesn't relate to you. This helps massively reduce inbox clutter.
The thing that bugs me about mailing lists the most is you get all the email, all the time, forever.
This is a total non-issue. Mailing lists support daily digests if you want that, and email clients support folders and filters if you want that instead. Nobody managing 5+ mailing list-based projects at once is dumping all of that into an unsorted inbox.
Because who doesn't like mucking around with their client's filtering?
Isn't there a decent mailing list package that hybridizes a GitHub "issue" type system with a traditional "email firehose" approach?
Because (your email client) is always going to be much, much faster and easier to navigate than "some dudes cute forum setup".
Replying to and managing conversations is much easier when you can do it with one or two keystrokes rather than mousey-mousing ten clicks all over the place (and oh their ad tracking js is stalling out again...)
I maintain that all web forums should have a mailing list interface so that you can use the forum without using the web at all ... but I suppose that breaks their revenue model ...
(Personally, I use GMANE+NNTP for mailing lists, and NNTP is probably better than plain (public!) mailing lists for most purposes, but unfortunately that ship has sailed.)
IRC is still an underused tool in my opinion. The ability to just talk about one issue in a Mail List and keep track of the communication is great. I can't think of another tool that manages communication as well as a mail list (Forums are just not as good in communication notifications like a mail list.)
P.S. I still hate Mail List and don't use them anymore but nothing does it as well right now.
IRC, like other chat and IM tools is synchronous. That is useful to get an issue solved quickly. But mailing list are asynchronous. People can think before answering and don't have to be around at the same time. Also threaded nature of mail makes it better to archive discussions and referencing them later. An IRC log is full of other noise and little structure.
If I want long-form messages delivered asynchronously, what other choices do I have (forums?) and why are they better than mailing lists? (everyone already has an email client.)
Or is it because you value the communication differently than the code? We've evolved distributed revision control to handle issues or geography, connectivity, and work styles effectively allowing you to be self-contained and then collaborate (push, pull, merge someone else's stuff) when you are ready to. Email is the only generally available method of communication that works the same way.
I'm the project lead for LXQt (http://lxqt.org). We inherited some infrastructure legacy from LXDE, which was hosted on sourceforge. Today, we have moved most of the legacy to Github but we're still using Sourceforge's mailing list system.
We're moving to a self-hosted mailman3 instance but it's been excruciatingly painful. Email is not fun to deal with.
So I'm pitching this to bored devs and entrepreneurs: Help us, and many other projects, by creating a "Github for mailing lists" with a web client featuring a clean high quality UI, easily browsable/linkable archives, etc. Make it open source, make it self-hostable, stuff in enterprise support. Make it quick and easy to create new lists.
This model can work. It's not unheard of either (cf. Discourse), but it just hasn't been executed properly yet, or is forum-only and does not support email properly. Right now, the UX of mailing list software is like IRC's. Very raw. If it were made more seamless, more approachable, overall easier, it would have a similar effect as Slack has had on unthreaded-async-topical-conversation.
PS: You should change your adblocker to uBlock Origin. It blocks Sourceforge as a malware risk.