Hacker News new | comments | ask | show | jobs | submit login

Something came up last time Sourceforge was discussed here, namely "why are projects still using it?"...

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.

High-profile projects actually can't stop. If you attempt to stop using Sourceforge, they will consider your account "abandoned" and continue mirroring the new site and serving downloads with their malware dropper included. So if you want to keep the malware out of your releases, you need to maintain control of your project by keeping SourceForge up to date.

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.

When I had a project that I started on sf and later moved off, I kept the sf project technically alive, but removed all downloads. I updated with links to the project site.

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.

"Since the content they host is open-source, this is technically legal, but it's scummy as all hell."

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?

Simple bundling is not a GPL violation, only linking.

Is there any license that prohibits this then? If not, should one be created?

If there was, it wouldn't be open source. The Open Source Definition explicitly prohibits any license that restricts simple bundling [0]:

> 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.

[0] https://opensource.org/osd-annotated

[1] http://www.debian.org/social_contract#guidelines

Yeah I still can't believe how scummy sourceforge is. I wonder how new oss projects can protect themselves against this type of behavior. Anyone know if any oss licenses include a restriction against this kind of repackaging or any kind of malicious use clause?

That would be contradiction of terms. Anything with such restrictions is, by definition (look it up!), not Open Source.

Sure if you want to be pedantic about it...

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.

Then we should all probably point our collective fingers at google. Let's not pretend they couldn't blacklist sourceforge links for pulling this kind of BS.

D has the best mailing list interface in the world by an enormous margin.


(The forum is a front-end to the mailing lists / newsgroups.)

The cool thing about D's forums/feed is how amazingly fast they are. I wish more web apps were designed like this, with a fast backend framework.

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.

The language used for a server backend is far from a guarantee of efficiency and performance. It's very easy to write a D or Rust backend that doesn't optimize queries and handles caching badly; you'll get just as terrible response times from those as you would on the "typical" slow websites that you refer to.

I don't know what you mean by fast, but https://www.ruby-forum.com/ seems to load pages faster than most websites, and as fast as D's forums.

According to a quick check the forum.dlang.org initial page view takes 200ms. ruby-forum takes 738ms. If you want to talk RUM/page load metrics forum.dlang.org takes 800ms for the load event to fire, the ruby forum takes 1.6s.

The individual posts load really quickly, but the main page doesn't (well not as fast as the other one mentioned). Either way, both are fast and I wish more websites were like this, not just forums!

> Instead, it's all either slow, slow backend frameworks like Ruby, or even

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.

It depends heavily on what you are doing. Most CPU intensive Tasks are fast on everything. However on Memory intensive Applications Ruby and Python are really really aweful slow.

most slowness you are talking about is usually database and/or caching related

with that said, that forum is certainly blazing fast for page views

To be fair, the content of that forum could probably fit inside the RAM. And it's not doing anything fancy like sorting, etc.


Do tell, please.

Excessive pagination is annoying, but speed... the speed is amazing. 240 ms from initial mouse click to fully rendered page. Due to fast response, I really liked to use that site.

Very nice.

Looks nice!

The source code running it - https://github.com/CyberShadow/DFeed

I love D's community to have their forums also accessible via NNTP.

In the same vein, nim forums are written in nim and are exceptionally fast and responsive http://forum.nim-lang.org

FWIW, I find the information density of this site quite low. When I visit these archives I'll generally read with via the gmane frame interface.

Hit Settings in the top right then choose Horizontal or Vertical split.

> So I'm pitching this to bored devs and entrepreneurs: Help us, and many other projects, by creating a "Github for mailing lists"

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.


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).

"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."

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.

[1] https://lists.freebsd.org/pipermail/freebsd-fs/

I'm not touching your lawn. I'm not even in the same city. If what already exists does the job for you, good on you. It doesn't for us, and many other projects.

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.

and if you want a better UI, wait until someone upgrades it to Mailman 3 I guess?

I agree. Mailman is fantastic as it is. There's a technical brevity and image it gives off, and that's an important aspect of design. This isn't really a statement about usability or what's beautiful in design.

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.


Personal attacks are not allowed on HN, even when someone seems arrogant. Please post civilly and substantively, or not at all.

Arrogance is telling someone they don't understand something, when they tell you "no."

> "User needs"

Do you actually design anything?

You're not telling me no, most specifically because I'm not pitching this to you. You're telling yourself no. You say you don't need it, and extrapolate your view of the world to everybody else's.

Really dangerous.

Does http://librelist.com/ match your requirements?

"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."

Not even close. Librelist's UX does not at all match what I describe.

Does it install trojans in your binaries?


Self-hosting seems like overreaction for most open source project. I would just make regular backups/exports. Dealing with spam filters etc is a nightmare.

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.

Isn't this what Google Groups is used for? (what's different / lacking there? I'm of the age where I remember SourceForge as somewhere I would sometimes download things from as a young teenager but nothing more than that)

Yes, Google Groups is very close to what's needed - unfortunately, it's proprietary and Google doesn't really maintain it, it's only a matter of time it goes the way of Reader.

FWIW, Google Groups powers email distribution lists for Gmail for Work. Or at least, the two are strongly linked.

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.

As someone using Gmail for Work: This is one of the things I absolutely detest about Gmail for Work. The Groups interface is absolutely horrendous, and we don't want groups, we want simple email distribution lists.

Do you know if people can manage their subscriptions themselves? I seem to be able to add "Admins" to a group, but I don't know what that does.

That's interesting, but it doesn't reassure me much. The infrastructure behind Groups may be in use, it doesn't stop Google from shutting the UI down.

To be clear: it's not just the infrastructure; the set up a Google Apps mailing list you use the Google Groups UI.

Well, they already shut down the free tier of Google Apps, which was also used by some OSS projects.

So it’s possible.

Didn't they grandfather in those that were in before that point?

Yes! I currently still use my apps.google.com account for free.

IMHO, the UX of Groups is really annoying. I'm not really sure why, it just feels so cumbersome.

Also, Groups doesn't have the ability to import archives from my previous list. (I'm in exactly the same position of wanting to migrate away from SourceForge, and the mailing list is the last thing remaining.)

Don't forget than when they do maintain it they make the UX worse. Every damn time. Over the years it's gone from mediocre to downright horrible.

Why mailing lists are still quite massively popular in 2015?..

How would you replace them? ( Please don't say Slack. That is just _not_ a good replacement, especially for projects that needs publicly searchable archives. )

IMHO a publicly/semi-publicly logged irc channel would do just as well, but that's even more oldschool.

The alternative is pretty much only online forums. Which imo. doesn't offer a lot of advantages, and most forum software is exceptionally bad (though yes, a few new and nicer ones are coming along)

Discourse NodeBB and Vanilla comes to mind

None of them appropriately support mailing lists, though. Email-based communication is a big deal for devs which contribute on maybe 5+ projects at once and have to manage comms in one central place.

As for Discourse's mockery of a mailing list mode, let's not even talk about it.

Are you familiar with DFeed [1] used by the D-Lang forum [2]? It is, in my opinion, one of the most usable web frontends for mailing lists (as well as a few other sources).

[1] https://github.com/CyberShadow/DFeed

[2] http://forum.dlang.org/

Never heard of it. Looks quite good. I will keep an eye on it, thank you.

If you're managing 5+ projects at once, your inbox must be a train-wreck of garbage from these mailing lists.

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.

>If you're managing 5+ projects at once, your inbox must be a train-wreck of garbage from these mailing lists.

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.

> and email clients support folders and filters if you want that instead.

Because who doesn't like mucking around with their client's filtering?

Ever heard of Sieve? ;)

Ever heard of it's 2015 and I'd like to be able to opt-in to specific mailings if necessary.

Isn't there a decent mailing list package that hybridizes a GitHub "issue" type system with a traditional "email firehose" approach?

Mattermost is a free and open-source alternative to Slack, giving users publicly searchable archives, great for sending images, files and code in chat. http://www.mattermost.org/

I have never used mailing list so I'm probably naive, but what about github issues?

Mailing lists are not just about issue tracking (and really shouldn't be about it). There's general discussion on them, release announcements, etc. pp.

"Why mailing lists are still quite massively popular in 2015?.."

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 ...

You can look at it this way: They're doing something that people want and which cannot be achieved through other means. What alternatives do you suggest?

(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.)

> Why mailing lists are still quite massively popular in 2015?..

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 is still an underused tool in my opinion

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.

Why shouldn't they be?

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.)

There's no alternative that's even close to that. For me email and IRC work for years and everything is going well.

I have to ask, is the question because you don't understand the value of the communication? There are definitely a type of greenhorn codes that don't and have never worked on anything with the scale to understand it.

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've always found the Sourceforge mailing list archive interface to be one of the worst out there. Sure, it's a lot prettier than the raw, unstyled HTML of the Mailman default but it's just not nearly as usable.

Savannah provides mailing lists. I don't want to advocate savannah too much, because the site isn't pretty, their interface is sometimes strange, they don't default to https, there are lots of reasons not to like it technically. But it's probably a place where you don't have to expect evils like supporting bundled Crapware. The FSF is behind it.

Hosting isn't the problem for us, UX is. We intend to self-host since we want to use @lists.lxde.org as an endpoint.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact