What Have We Learned from This Open Source Project?
taskwarrior.org
taskwarrior.org
Ugh, very true. Folks forget that most FOSS work is volunteer & berating the hackers who make it won't help one bit. Worst is the issue reports about a fixed bug, followed by "What version do you have?" aaaaand silence. At the very least come back and close the issue.
What are we doing next, what version did we fix Y in, what VCS branch are we working on Z in, who is working on X, etc. are separate from Who reported problem, what version of the product do they report having used, what did they expect and what did they get, is that part of the design of the product, did they ever get back to us, etc.
The other problem is ill-defined roles. If everyone's a developer is a support volunteer, is a user, then you can have people be pretty shitty and reflect on the project in a way that they shouldn't be allowed to.
Random users should be able to file support tickets, but only to view project management tickets.
Only designated volunteers should be able to respond to existing support tickets and create project management tickets from them, these people speak as the public face of your project, that's really really important to have a handle on.
Support tickets probably shouldn't be public, for that matter.
Now of course this is all unpaid, volunteer -- I'm not saying any of these queues should have a defined SLA or anything. By all means keep project a bazaar -- let support queue handle outside feature requests and feedback and everything -- continue to have a public repos, roadmap and changelog, etc.
> Support tickets probably shouldn't be public, for that matter.
Open GitHub issues, combined with Google, have turned out surprisingly useful to me as a user of open source packages. Often an answer to some trouble I've run into is found in an issue -- both 'support' ticket style issues, and development roadmap style issues, and the line sometimes gets blurred.
Also, there's a positive aspect of the blurring of the boundaries in open source -- when a user contributes code, or documentation.
But yeah, people running open source projects need to at least think about how they're going to deal with project management as well as support at some point, and just the thinking about it and the iterating to figure out how to do it better is for some a chore they don't want to do. The projects that figure out how to do this well are the ones that are a joy to use or to contribute to though.
Oh, and my experience I'm talking from is with open source code packages meant for use by developers. Open source end-user applications (including OSs like Linux) are a different animal, and are _much harder_ to deal with support and project management and the overlap, in my observation. Not sure which you were thinking of, but now I'm thinking maybe end-user apps.
There's also nothing preventing common support issues getting turned into documentation improvements, creating googleable (but more concise) results. I'd rather find a wiki page for "libchitz Error: Insufficient Flurbos in /var/lib/blips" than a forum post/issue with tens of comments and have to scrape through the results.
Also, there's plenty of times googling something should get you a documentation page on a subject but instead gets you forums/issues/etc. that aren't helpful.
Nothing but someone with the time, willingness, and skill to do it well. Which is not nothing. A lot of the amazingness of GitHub's effect on our work is how it gives us lots of useful stuff that happens as 'byproducts', without someone needing to spend time and energy to do it well.
- https://www.jwz.org/blog/2013/02/wow-remember-when-people-tr...
It’s hard to find a good solution.
Which a lot of people in the free software crowd dislike, because of privacy implications. I, personally, dislike it, too.
One repeated theme is what people won't talk about, do talk about, and loudly social signal about, generally have nothing in common, so assuming any of those individually is a universal truth is likely to be a disaster. This applies to a lot more of life than just FOSS development.
As an example of contradiction was the claim that people won't read the docs but they will watch animations. The reality as seen above is 99% of the population will read the docs and never contact you unless your docs suck, 0.9% will watch the pictures, and 0.1% will aggressively track you down and ask you to read the docs for them. Although adding animations will cut annoyance contact by 90%, that doesn't mean gifs are the only thing that matters; the docs are what's really important.
The irony of people getting annoyed because of "missing restrictions".
Like lots of open source folks I know, I'm personally a fan of the underpinnings of apps/servers as well as libraries being permissive (BSD/MIT) so that everyone can contribute/benefit but full applications being GPL. To each their own, of course, and there are many rationales for differing views. But please don't belittle others' takes on what they choose to do with the effort they put in.
(Conservancy, one of a tiny number of organizations that does this work, has been having a lot of financial troubles lately: https://sfconservancy.org/)
As you said the software freedom conservancy is having financial troubles (why the Linux foundation doesn't just cut them a cheque is beyond me). However, a lot of embedded systems use BSD and other such systems. And ultimately, that's not the point I was making. The point is that the GPL not allowing proprietary forks is a benefit (both from a freedom aspect, but also from a technical aspect) and has given us all much better technologies as a result. The "freedom" to make proprietary software (which is a misuse of the term) is a tiny "benefit" (I don't think it is a benefit) when compared to the end results of GPL software like Linux.
(I guess another question is to what extent there are people actively scouting for useful stuff to merge upstream; are there kernel trees with useful fixes or enhancements that are published never merged into the mainline kernel because nobody notices?)
There's no guarantee that a random open source project will have any new releases at all. In that case, what good is a promise about its license?
Or if they do happen, the code might change in a way that's backward-incompatible so you can no longer use it.
The only guarantee you can count on is that if the code you actually have doesn't suit your needs, you can change it yourself.
Sufficiently unrestrictive licenses (ex MIT) allow anybody to use the code for whatever their purpose, commercial or otherwise. Even then, prior art limits others from seizing ownership and limiting access to the original creators/contributors.
Disclaimer: IANAL but this is only my understanding from working in OSS.
I guess, I hadn't much considered whether that was a thing one could do.
That is my whole point: MIT and BSD code is free-er than GPL and AGPL because you can go from MIT and BSD to AGPL but not the other way around.
The original code will still be under the permissive license. But you can take it, and fork it, and continue to develop the fork, and all your new additions can be licensed under the more restrictive one (including GPL).
To be clear about what's going on, you could put a notice saying that anything taken from Source Project X was MIT, all further changes were (GPL). Perfectly legal. But really, how would people know which parts are which except diff'ing it, they might as well just go back to the original -- or they can always diff if if they want regardless of license of course. MIT/BSD don't require attribution or anything, they just say do whatever you want with the code.
So forking and just saying "the license is [eg] GPL" is pretty much the same thing. It's legal. You can't stop people from continuing to use the original code without complying with the GPL, but your fork is GPL.
IANAL. Maybe if it ever got litigated it'd end up different. It might not get litigated, for a while.
With BSD code, the majority of devs can always sell out, and make sure all future modifications are purely proprietary.
We’ve seen that happen on Android.
Nowadays neither the launcher, nor the keyboard, nor the dialer, nor the contacts, nor the calendar, nor the device search is open source anymore.
A lot of code that ended up under free licenses has been proprietary first and while they cannot revoke the free licenses from already released code they can make their next release non-free as long as they haven't accepted outside contributions without a suitable contributor agreement.
Not all contributor agreements are equal, and I would recommend choosing which projects you will not contribute to based on their CLAs. If they ask you to give them copyright without good reason, they are preparing to fuck you over. Ironically, this is why I will not contribute to GNU because they require copyright assignment so they have a higher chance of winning conservancy cases (IANAL, but I have one in my family and this is bullshit in my country but may be true in the US, so I feel conflicted about it).
> A lot of code that ended up under free licenses has been proprietary first and while they cannot revoke the free licenses from already released code they can make their next release non-free as long as they haven't accepted outside contributions without a suitable contributor agreement.
The only example I can think of is OpenSolaris (which required contributors to sign a CLA that assigned copyright to Sun/Oracle). Most modern projects don't work like that, and if you have a copyleft license, a company could not legally create a proprietary fork and distribute it.
Besides, if that happens you end up with free software forks (illumos in the OpenSolaris case) and everyone moves to using that.
(a) it's someone trying to force their values on someone else in the name of "freedom" (in scare quotes because it's a very specific definition of the term that requires political buy-in to even see it as a form of freedom)
and
(b) as stated, the people complaining are free (no scare quotes) to take the permissively licensed code and incorporate it into their "free" code to their heart's content. The ability to do this is one of the reasons people choose permissive licenses in the first place.
I don't care if people choose freedom or "freedom" or anything in between- that's their right as authors, and no one license is appropriate for all communities or goals or projects. I only object to anyone who claims that there is a One True Path that everyone should follow and that anyone who doesn't follow that path is somehow morally inferior, which is usually the template that these discussions follow.
The problem is that allowing proprietary forks is shooting yourself in the foot if you believe in free software being a net benefit to society. Allowing proprietary forks of your software to exist means that you are fighting against yourself to produce free software. Not to mention that it means that users of your software might not have the freedom you intended them to have if someone else packaged your software.
> "freedom" (in scare quotes because it's a very specific definition of the term that requires political buy-in to even see it as a form of freedom)
Which of the four freedoms do you think are restricting users? If you're referring to copyleft (this is not the same thing as freedom), then please understand that copyleft software ensures that all users that receive the software will have the benefits of free software. That's the whole point.
> ... The ability to do this is one of the reasons people choose permissive licenses in the first place.
It also allows for proprietary forks, which is why some people have a problem with it.
> I don't care if people choose freedom or "freedom" or anything in between-
Seems like you do. I don't get why you quote the word "freedom" when referring to copyleft but don't quote it when referring to the "freedom" to make proprietary forks of free software. It should be the other way around IMO.
John Locke describe freedom as a synonym to agency, where none is under any restrictions except the standing rules to live by that are common to everyone in the society. Share and share alike a perfectly fine example of a rule that is common to everyone where no individual are be subjected to the inconstant, uncertain, unknown, and arbitrary wills of others.