Fork YOU! Sure, take the code. Then what? There's an old adage in the open source world – if you don't like it, fork it. This advice, often given in a flippant manner, makes it seem like forking a piece of software is not a big deal. Indeed, forking a small project you find on GitHub is not a big deal. There's even a handy button to make it easy to fork it. Unlike …
Distrowatch tells me the most recent distribution based on Debian is Bodhi, which came out yesterday. For a proper fork, I would guess Devuan.
I had great early success with it but then it began acting funny. Initially it would stop syncing then not much longer after it began destroying the data.
Nothing untoward was happening on the server as far as I could see.
But the lack of delta updating of files was more of an issue to me, so I swapped some time ago to Seafile and frankly haven't looked back.
But good luck to them all.
You're also missing out on the moans along the lines of 'I posted a bug ages ago (see minutes/hours/days) and it hasn't been fixed, so obviously this project isn't being actively developed!'
Usually after explaining that it's not a paid project, and the bug isn't a critical one, and that there are other more pressing issues to resolve.
You can always get them to shut up by telling them to fix it themselves on their own fork, thus helping everyone out.
(usually ends with the commentard equivalent of staring at their feet muttering "s'ok, i'll wait.....wasn't that important....mumble, mumble").
Is that a rhetorical question?
Communities come and go. I've seen – in my 30 some odd years working with FOSS – communities wax and wane. In one cases I saw a community evaporate over night. And coalesce elsewhere to continue the work.
Anyone who thinks they can control, never mind own, a community is smoking something serious.
As long as you stick with the GPL, that can work.
If you used a BSD or Apache licence, any fork can be distributed binary-only and still be considered Open Source -- the licence isn't preventing you from distributing the Source Code, but neither is anyone under any obligation to give it to you.
If the forked version is subtly incompatible with yours, but backed by a big enough organisation, it can end up stealing your thunder.
Why do you think Google love the Apache licence, and hate the GPL?
"Why do you think Google love the Apache licence, and hate the GPL"
Remind me again which kernel underpins Android and which licence it is released under?
Let's look at the Google Summer of Code,
"a global program focused on introducing students to open source software development. Since its inception in 2005, the program has brought together almost 11,000 student participants and 10,000 mentors from over 113 countries worldwide."
Here are the projects that have benefited.
Google manged to find a loophole, you can't have free and open source software on locked down proprietary hardware. In case you missed it, GSC speaks about open source software. The word "free" (the F in FOSS) is missing and GPL is all about that. As I read it, the goal of GSC is the train a crop of developers that will continue to donate their code to the mighty Google who can make billions with it. Google succeeded where Tivo failed.
Apple on the other hand, did not want to bother with GPL, instead they went and pilfered BSD code. Again unlike Google, Apple now prefers to pay the developers for their ideas instead of introducing students to open source software in order to steal their ideas.
Pilfered is certainly not the best or most legally accurate term. One problem with the term "pilfer" is that, according to the dictionary, the items stolen are usually of very little value. Off hand I wouldn't say that BSD is of very little value.
I'd posit that if Apple wanted to be good citizens in the FOSS world they'd give fixes and enhancements back regardless of what the license may or may not force them to do. Ditto for Google – particularly the user-space parts of Android that are under the BSD license.
When they just take, and never give back, they may not be stealing, but they are taking. In a world where it's all about how things look, they would certainly look better if they weren't only taking.
From the FAQ
Is Google Summer of Code (GSoC) a recruiting program?
No. If you are interested in working for Google, please visit the Google jobs website.
Is GSoC considered an internship, a job, or any form of employment?
No. GSoC is an activity that the student performs as an independent developer for which he/she is paid a stipend.
Are mentoring organizations required to use the code produced by students?
No. While we hope that all the code that comes out of this program will find a happy home, we don’t require organizations to use the student's' code.
Do I get paid for participating in GSoC?
Yes! Google will provide a total stipend of $5500 to those students who successfully complete the program
"Apple on the other hand, did not want to bother with GPL, instead they went and pilfered BSD code. Again unlike Google, Apple now prefers to pay the developers for their ideas instead of introducing students to open source software in order to steal their ideas."
Given how many kernel (and other) developers Google pays and how much code they shove upstream, I would have to call this statement out as blatantly false.
Complexity... it is all complexity isn't? always the bloody complexity.
Who's there knocking at the door? it's complexity.
You can't kill complexity, nor reduce it significantly beyond a certain scope.
The only silver bullet for complexity is: PEOPLE.
People that can deal with it that is.
> The only silver bullet for complexity is: PEOPLE.
There is no silver bullet for complexity.
But from all I have seen and learned I gather that for any nontrivial project you need to have at least one person who is on top of things. If you don't, things will fail and NO amount of people and NO buzzword of the year technique is going to help.
Beer, because [reason].
Complexity is the enemy of execution. Years ago I was involved with a large Bill Of Materials and Project management application for an automation house. There were many facets to the overall project, an RFQ system, QA and change management for engineering drawings, costing, shipping and receiving etc. The end product was simple to use, so much so that one manager questioned why the company threw all that money at the project when it appeared that a file manager and a spreadsheet could do the job. I thanked him for his critique and invited him to try as he suggested. He took me up on the offer, and failed. The initial impression of simplicity and ease of use was deceiving, and he later complemented us on the effort we put in to hide the underlying complexity of the application from the user.
...I still use it, partially because the kludgy home made font rendering library works slightly better than the *current* state of the refactored OS provided font rendering used by LO on my particular OS. But also because I know where the bugs are. And I have become fond of some of them...
http://www.joelonsoftware.com/articles/fog0000000069.html
Beer: to all involved wit Open Source / Free / Libre software in any capacity.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
