Tau: [HELP] Petition to keep Flutter Sound as a free project

Created on 8 May 2020 · 1Comment · Source: Canardoux/tau

Petition to keep Flutter Sound as a free project

We (the Flutter Sound developers and users) are very concerned by the apparent attempt of someone (@bsutton ) and his private company to take control of Flutter Sound.
We cannot accept that someone (and more a private company) takes control of Flutter Sound.

We do not accept that someone arrives and says :

"Flutter Sound is just bullshit. I rewrote everything. No backward compatibility. Just replace everything by my fork without any discussion. Take the whole thing or take nothing."

If this is the offer, of course we will decline it. Event if there is perhaps great things in this fork. Because our freedom is more important than everything else.

Flutter Sound kept backward compatibility between V2.0 and V3.0 API, and after from V3.0 to V4.0 API.
But maybe it is time, now, to do some breaking changes to V5.0. Less change it will have and better it will be.

We want to participate to the `Functional Specifications". We do not accept that someone arrives and says :

"this is the 5.0 API. No discussion possible."

We want to be able to discuss every breaking change. If there is no consensus, it will be time to vote. If the vote is not conclusive, then the breaking change will not be done. This is what is called direct-democracy and self-management.

We want that those Functional Specifications are written down and approved before coding the first Dart code line. Those Functional Specifications will be the API documentation of V5.0.

Of course, every body may create a new fork from Flutter Sound. This is part of the freedom. The only obligation is that this fork must be published under the LGPL license. But we will love the guy/girl responsible of this fork (@bsbutton !) if he/she takes time to push the new features of his/her fork into the Flutter Sound project, so that Flutter Sound will continue to be the best flutter plugin to do sound.

Flutter Sound must stay free
(Flutter Sound developers and users)

help wanted

Source

Larpoux

👎9 👍7

Most helpful comment

Sigh.

Yes the proposed dev branch does contain a number of significant breaking changes.
However the flutter_sound (FS) api is quite small and a migration guide has been provided.
It took me about 10 minutes to convert my own project from the 3.0 to the dev branch api, so not exactly earth shattering in nature.

From the start I've engage with the FS developers. You can see the large amount of conversations in the issues and in the PR requests.
I've also spent a no. hours on video calls with @larpoux.

I've gone through 3 iterations of the api based on feed back fro @lapoux.

So why the breaking changes.

The 3.0 (and now 4.0) branches have a number of significant bugs and missing features.
In particular the dev branch contains a number of fixes for race conditions, null pointer exceptions and resource leaks.
Of particular note (apart from the above crashes) the android code completely fails to handle app pause and resumes which can leave your android sound hardware unavailable to other apps.
The 3.0/4.0 dart code has numerous issues including:

incorrectly coded futures.
resource leaks
inconsistencies in the api
large quantities of duplicated code.
an api that is in need of a major overhaul.

The approach proposed to fix these issues by @Larpoux was to push a stream of small fixes.
The problem with this approach is that the system requires a major re-architecture and continuous small fixes would result in continuous change to the api. The result is that every change would be a breaking change. In the last month we have already seen 4.0 released and as I understand it another major release is in the works with further breaking changes.

The reality is that the 3/4 code has been evolved by a number of part time developers non of whom have fully understood the code base. This is not meant as a criticism simply a statement of fact, one that is common for many open source projects. If FS is to dependable then it needed a major overhaul.

The approach I've taking (and stated up front) is to make one large set of breaking changes which would allow the re-architecture the api in such a way that we should be isolated from breaking changes in the future. The design has very much been about having an api that is ready for the features that we can reasonably expect for the future.
Again 'large' is a relative term as the FS api is tiny.
I've also been asking to get the dev branch pushed to pub.dev so we can get user feedback and make any necessary changes to the api before we lock it down.

I think the above demonstrates a willingness to engage and discuss api changes.

@Larpoux statements of a take all or take nothing approach is true but wrong.

The dev branch is a major rebuild of the code base. @Larpoux has asked me to back port the fixes that I've made. For the dart code this simply isn't practical as the code is vastly different.

All the changes that I've made to the java code have been pushed as I've made those changes. With a few very minor exceptions those changes are compatible with the 3/4 branch. At any point in time @Larpoux could have (and still can) take those changes and apply them to the 3/4. I've added significant documentation/comments to the code to make it clear what work I've done to the code.
I was actually in the middle of preparing a push of the java code to the 3/4 branch when this issue popped in my feed. I will still try to get that push finished this weekend.

So lets get to @Larpoux statments about a free FS.

Do I work for a private company?
Yes (full disclosure I'm a significant share holder).
Has the company paid for my involvement in FS.
Yes
Do we have any intent of somehow taking FS private?
No. and I don't see how anyone could draw that conclusion.
Over the past 6 weeks or so I've made hundreds commits on a public github rep and issued PRs to the main FS repo which have been accepted by @Larpoux .
My repo is:
https://github.com/bsutton/flutter_sound
Feel free to fork it. But then it's github so you don't need my permission.
Do we have any intent on somehow monetising FS?
No. We are using FS for an app that we are building and we have freely contributed all the code change we have made and will continue to do so.

The company I work with has extensive involvement in a number of open source project.
We have always welcomed any contributes and freely given out write permissions to anyone that was interested and demonstrated a reasonable level of competency.

Here a some of the ones that I manage:
https://github.com/bsutton/dshell
https://github.com/asterisk-java/asterisk-java
https://github.com/noojee/money.dart

There are many more I contribute to. You can see my contributions on github.

So where to from here?
I suspect that no one will take much notice but if you care then make a comment.

From here my choices are:

1) try to reach some consensus and get the dev branch released in a coherent form.
2) fork FS

I would prefer option 1 and perhaps if users of FS care enough to review the code and provide feedback on which direction users of FS would prefer to go that might help us find a way forward.

You can view the read.me for the dev branch (which is referred to in the read.me as 5.0).
Its still a work in progress but provides a fair no. of examples on how to use the new api.

https://github.com/bsutton/flutter_sound/tree/dev

Here is a summary of the changes in the dev branch:

SoundPlayerUI widget
SoundRecorderUI widget
RecordingPlaybackController widget (pairs a recording and player widget).
QuickPlay for short audio playback.
consistent api (e.g. consistent usage of Tracks, naming conventions...)
Fixes for jank when starting a player
Fixes for a no. of crashes due to race conditions during initialisation
Support for app pause/resume
Fixes for Future handling (causing more jank).
Improved api documentation.
Improved streaming model for duration/db tracking
Cleaner public api - I've worked to hide any internal methods.
cleaner permission model.

I've also proposed a new model for codec support which will make it easy for anyone to add new codecs and let devs pick and choose which codecs to support in their app to avoid code bloat.
https://github.com/dooboolab/flutter_sound/issues/344

I'm also keen to see a suite of unit tests to ensure the long term stability of the code (help wanted!)

Add your comments or just give a thumbs up on @Larpoux inital post or this one to indicate your preferred direction.

At the very least these post should give you a good laugh ;)

bsutton on 8 May 2020

👍28 😄1 👎1

>All comments