Closed tresf closed 7 years ago
StakeoutPunch
commented
7 years ago I've mainly been lurking and not chiming in, but I'm failing to see "hostile" behavior. Elaboration, perhaps?
(I would know all about hostility... look through my post history in this tracker :/)
BaraMGB
commented
7 years ago Hi Paul,
Open source development follows certain rules. In such a big team, which has grown for years, you have to earn your trust. We are a diverse group of developers with different skills. None of us can do anything equally well. That is why we must trust each other. This trust has grown over years. For someone new, it is harder to push through their ideas. Especially when things are as basic as the audio core. Open source development has always had something to do with compromise. If you think your views are correct, then you have to fight for it! I was very excited about what you would do for lmms and I am shocked that you give up so easily and go.
jasp00
commented
7 years ago @tresf, please reopen, this issue is important and we are not done. Thanks for contextual links.
@PaulBatchelor case First, let us see this case. The blog post is harsher than what you quoted. What has happened?
OTOH, ReverbSC has been accepted. This is proof that we value contributions from @PaulBatchelor.
IMHO, our behavior is impeccable. @PaulBatchelor is welcome to come back. His contributions will pass a review and improvement process, just like any of ours.
Other cases The issue is why we lose developers, so I will comment my case; I hope I can be tagged as "good developer". When I left the project years ago, I was reluctant to the model/view split as it is implemented. I had design disagreements with @pgiblock too. But I left the project because of another reason: lack of time. This is a frequent view, we do not want to waste time discussing, specially if we are convinced that we are right.
Lack of time. This is the same reason I may leave the project; there are external requirements that may force me to stop contributing. To keep these developers, you need to identify these external factors and dedicate resources, which we may not have.
I do not know why @tobydox, @pgiblock, @diizy or others left the project. Any manpower is valuable and we need to know why we are losing it. We should at least identify the causes even if we cannot solve them.
Then, there is the question of how do we gain good developers, but that should be in a different issue.
Proposal I propose we keep a wiki page with the following information sorted by GitHub id, filled voluntarily:
AndiEcker
commented
7 years ago @PaulBatchelor https://github.com/PaulBatchelor - please please please come back - you initiated a lot of great additions to LMMS - would be a shame to leaf them dangling after your great contributions....
2017-03-21 15:32 GMT+00:00 Javier Serrano Polo notifications@github.com:
@tresf https://github.com/tresf, please reopen, this issue is important and we are not done. Thanks for contextual links.
@PaulBatchelor https://github.com/PaulBatchelor case First, let us see this case. The blog post is harsher than what you quoted. What has happened?
-
3412 https://github.com/LMMS/lmms/issues/3412, "changing to MIT
license for easier plugin development". A GPLv2 plug-in is not harder to develop unless you depend on proprietary code. Speaking for myself, we have a commitment to protect the freedom of users. But if you want to sell a proprietary plug-in, you may do so; not easy, but feasible. I believe this issue has been handled correctly.
3422 https://github.com/LMMS/lmms/pull/3422, "correcting an
accidental 10-year old bug". AFAIK, this is an intentional feature and I have stated https://github.com/LMMS/lmms/pull/3422#issuecomment-287530400 how to proceed. The issue is still open and I think our feedback is correct.
3404 https://github.com/LMMS/lmms/pull/3404, "fixing the
command-line renderer". I have suggested https://github.com/LMMS/lmms/pull/3404#issuecomment-287324004 a better approach and @PaulBatchelor https://github.com/PaulBatchelor has not reacted. The issue is still open and I believe our actions are right.
3416 https://github.com/LMMS/lmms/issues/3416, "suggesting the
removal of worker threads". No reproval has been done because of suggesting. The concern I raised was because a member with commit rights had a clear intention https://github.com/LMMS/lmms/issues/3416#issuecomment-286864793 of removing a performance critical component and no one understanding the current implementation was there to object. @tobydox https://github.com/tobydox made this component for a reason (and he was right). No actual implementation from @PaulBatchelor https://github.com/PaulBatchelor has been proposed. I have requested that such implementation were faster than current one, which I believe is a sensible request. Although there is disagreement, I fail to see hostility in the report.
OTOH, ReverbSC has been accepted. This is proof that we value contributions from @PaulBatchelor https://github.com/PaulBatchelor.
IMHO, our behavior is impeccable. @PaulBatchelor https://github.com/PaulBatchelor is welcome to come back. His contributions will pass a review and improvement process, just like any of ours.
Other cases The issue is why we lose developers, so I will comment my case; I hope I can be tagged as "good developer". When I left the project years ago, I was reluctant to the model/view split as it is implemented. I had design disagreements with @pgiblock https://github.com/pgiblock too. But I left the project because of another reason: lack of time. This is a frequent view, we do not want to waste time discussing, specially if we are convinced that we are right.
Lack of time. This is the same reason I may leave the project; there are external requirements that may force me to stop contributing. To keep these developers, you need to identify these external factors and dedicate resources, which we may not have.
I do not know why @tobydox https://github.com/tobydox, @pgiblock https://github.com/pgiblock, @diizy https://github.com/diizy or others left the project. Any manpower is valuable and we need to know why we are losing it. We should at least identify the causes even if we cannot solve them.
Then, there is the question of how do we gain good developers, but that should be in a different issue.
Proposal I propose we keep a wiki page with the following information sorted by GitHub id, filled voluntarily:
- Id
- Reason to join in one line.
- URL to further information.
- Reason to leave in one line.
- URL to further information.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/LMMS/lmms/issues/3447#issuecomment-288116868, or mute the thread https://github.com/notifications/unsubscribe-auth/ADlPbizSpHgOiqwGZ1Njcfb68HvJQIXlks5rn-17gaJpZM4MjQqU .
PaulBatchelor
commented
7 years ago I've unsubscribed from this feed, and I've been only gleaming over the comments getting the gist of things.
A few additional thoughts:
tresf
commented
7 years ago @tresf, please reopen, this issue is important and we are not done. Thanks for contextual links.
I've created a new conversation tag for items like these. The open/closed status is arbitrary. It's closed from a bug tracker perspective. It is not locked. (We generally don't lock threads).
This thread is still open for discussion.
@jasp00 re: #3422
Mar 18: Wet/dry formula is correct [...] I do not remember whether this was intentional.
Mar 21: this is an intentional feature
First, you're contradicting yourself. Second, you're in risk of bringing this off-topic if you choose to argue each point here. (I guess that makes me no better? Continuing...)
@jasp00 re: #3416
@tobydox made this component for a reason (and he was right)
As a product -- as a whole -- stability, consistency and quality are paramount (and "right"). From a productivity and stability point of view, I'm very interested in a single-threaded version. If it's not too complex to implement, I'd like to see how well it performs. As an end-user I'm really sick of unpredictable sounds. There's really no trade-off between stability and performance. Without stability, performance is simply a very fast car-crash.
@jasp00 re: #3412
A GPLv2 plug-in is not harder to develop unless you depend on proprietary code.
GPL2 is problematic for plugins. MIT opens doors for commercial but also proprietary but it's simply less restricting, like CC0 samples. Regardless, "commercial" is not the only incentive, it's just a better license for interfacing. But sometimes, it's not the decision that wears out a programmer, it's the push-and-pull when there's no clear decision to be made. Fortunately we did eventually settle on an agreement (focus on LV2), but we still require a programmer.
IMHO, our behavior is impeccable.
I tend to agree holistically, but it's a hard road getting there.
fundamental
commented
7 years ago @PaulBatchelor In case you skim the thread later on: There was no intended hostility on my behalf, though I could see how some of the snark in the licensing thread and the verbose responses in the mixer thread could be construed as such. In both threads I attempted to steer discussion to what I considered a more reasonable scope based upon what I've seen about LMMS, but there may have been several miscommunications along the way.
For the record I agree with the general opinion on LMMS's codebase:
Look, LMMS hasn't had a real audio developer in a very long time. Maybe never, from the looks of it. There are a lot of foul things I found in the source code Minus the licensing, these are all show audio stoppers as far as I'm concerned.
@jasp00 re:
I propose we keep a wiki page with the following information sorted by GitHub id, filled voluntarily
In an ideal world that would produce useful information, but similar to corporate exit interviews people will withold information to avoid burning any bridges. This would (IMO) result in people avoiding discussions on the social/political structure within the project (which something the size of LMMS certainly does have).
As per the overall topic of "Why do we keep losing good developers?" I think there's a variety of reasons at work here. LMMS is in a unique position in that relative to many other projects it attracts more developers than other similar scoped projects (from what I've researched in open source linux audio). So, with that in mind I think that LMMS needs to focus on the smooth integration of new devs for the best overall results.
points in particular which seem to repel existing/future contributors (from my likely flawed observations):
I could likely continue the list for a while and quite a few issues (listed here or not) are more generic problems facing linux audio in general. In the past few years there have been fewer devs out in LA in general due to a combination of fewer people starting to contribute and more people leaving and choosing not to return. As the flow of contributors shift I think it's very valuable to look at what the problems are and how to address them to avoid projects turning into abandonware (or something close to it).
With that said, I'd like to address the last point somewhat.
@jasp00 Thanks for taking the time and effort needed to perform the numerous pull requests this past year (goodness there's ~80 of them looking at the list).
@tresf Thanks for managing the trackers here on github. Personally, I find it exhausting to handle support requests, so thanks for all the hours put in keeping the communications flowing.
Other LMMS developers, I may be unfamiliar with your particular contributions, but thanks for spending the time helping to build an open source tool. Free Open Source tools are an amazing thing which honestly can be an inspiration to individuals for them to learn something new or do something that they previously thought was impossible. It's easy for work to be lost in politics, or for it to be overlooked, but contributions are immensely valuable; so, thanks for helping out.
RebeccaDeField
commented
7 years ago @fundamental Since you've outlined most of the points I was writing up wonderfully, there is only one point that I would like to bring up on the topic of keeping more devs:
This is not to say that some of the contributors here do not already provide excellent feedback, but I think there is still room for improvement from the community as a whole.
It is a good general rule of thumb to give a positive with every negative comment.
See a problem? Try to also propose a solution. Don't like someone's work? It's still very helpful to mention what parts you did like. Didn't like any part of their work? Try to at least thank them for the effort.
It takes far less time to write up one positive sentence this than to sort out the miscommunications that often result in long and enduring comment threads, burnout and loss of devs.
To draw comparison from my experience in the design world: When people have constructively criticized my work, it almost always results in a better product. When people have given me feedback consisting only of vague, negative and personal opinions, it has almost never resulted in a better product.
You might think I am proposing that people hold back their views, and candy-coat their feedback, but this is quite the opposite to what I am saying. Brutally honest feedback is so valuable, but constructive takes the brutal out of it. This gives people even more freedom to delve into their criticism in a collaborative environment.
Keeping this in mind would also help people feel appreciated, which is sometimes an even more effective motivator for devs to continue their work in the long run than money could offer.
Umcaruje
commented
7 years ago
- I generally don't see much collaboration when it comes to code changes. There are cases where there's code review, but I don't see people really working closely together all that frequently
- Methods of communication and discussion for the project appear to be unreliable (likely due to the amount of support requests) e.g. lmms-devel mailing list occasionally gets queries but very few responses. the mixer thread which lead to this thread was not answered with any general information. The lmms IRC channel is pretty dead.
As far as communication and collaboration goes, we have a server on Discord now, and at least when it comes to the GUI designs we have pretty good environment over there, and there have been even more devs showing up there lately.
For example working on the theme/plugin designs was a charm because we would directly share mockups between each other and also get feedback immediately from the users. I've been doing the same for the website redesign, so I definitely think Discord's the way to go.
tresf
commented
7 years ago The only statement from @fundamental I disagree with is this one...
LMMS's windows based focus alienates linux developers who may have been exposed to other tools through existing plugin standards. The complex windows tool chain also makes it difficult for many people to improve the codebase (from my casual observations, LMMS/general-opensource devs tend to be on linux)
Albeit true we have 1.6 million Windows downloads/yr, the toolkit is barely windows, but rather is written against a cross-compiler that emulates POSIX. There are very few components where Windows gets in the way.
This statement may be influenced on the 137-comment-struggles we hit with Zyn 2.5 integration... but again, it was actually the lack of Windows-debug build support that stopped the release -- not the other way around.
Linux is still the predominant development platform from both an ease-of-building perspective, an accessibility of build-tools perspective and finally from a contributor standpoint. 🐧 (We just suck at packaging it for Linux -- but that's more of a Linux problem in general... and that's almost ready)
jasp00
commented
7 years ago Did I overreact in that post? Probably. Bad day, bad week.
We are human, @PaulBatchelor. Get over it and come back.
The open/closed status is arbitrary.
@tresf, I easily lose track of closed stuff. May I open a separate issue to handle my proposal?
First, you're contradicting yourself.
AFAIK means "as far as I know". I use this expression when I cannot point to evidence, but by the looks of the code I infer it is the case.
Second, you're in risk of bringing this off-topic if you choose to argue each point here.
@tresf, you wondered: "I wonder if something could have been done better here". So I have analyzed what has been done here to know if we could do better. I will discuss your arguments in the corresponding issues.
In an ideal world that would produce useful information, but similar to corporate exit interviews people will withold information to avoid burning any bridges.
@fundamental, this information voluntarily provided would help the project. Some people will withhold, some will be sincere, some will not write at all. It is a wiki page, not a stone engraving, users can modify text.
I really appreciate the effort all of you are dedicating to this issue, it is useful feedback, but the point is not to know what makes a good environment or what may repel contributors, but what actually drives developers away. We need data from developers that leave the project. @PaulBatchelor is one of them. I am one of them, this is why I shared my experience and I could share more.
So your answers to this question would be far more useful. What made you actually leave a collaborative project?
RebeccaDeField
commented
7 years ago We are human, @PaulBatchelor. Get over it and come back.
@jasp00 he already did.
EDIT: If you're not already on discord you might want to read over the logs in #devtalk.
jasp00
commented
7 years ago @jasp00 he already did.
What makes you think that? He says "I've unsubscribed from this feed" and gives some thoughts, period. Did I miss something?
jasp00
commented
7 years ago If you're not already on discord
I see.
tresf
commented
7 years ago May I open a separate issue to handle my proposal?
I feel it would be more effective to simply contact those who have left and document in this thread. @badosu and @curlymorphic are two that come to mind. I'd also like to hear from @Fastigium. I think the wiki needs to be streamlined more, not become an archive for testimonials and exit interviews (to paraphrase @fundamental a bit).
For example, the licensing article recently written has a home in coding standards. If one needs to direct-link, just give it a proper markdown heading and use the hash URL.
I easily lose track of closed stuff
I lose track of needles in haystacks (570 bugs and growing). If people are only looking at open bugs, they should go to the last page in my opinion. (if a bug has been open for that long we've needed for a long time).
I can't speak for the best way to manage so many issues without creating meta issues, which have been working OK, but closing conversation threads at least separates them from the coding problems.
Get over it and come back.
I think there's a slight bit of perceived/unintended rashness in statements like this. :) <3
fundamental
commented
7 years ago @Umcaruje I'd say that the ongoing plugin design thread(s) are a great example of how development should flow and the plugin design work was one of the very few exceptions to my complaints.
@tresf Per the windows comment, I stand by it, though I certainly am colored by the slow-motion-trainwreck which was what happened in trying to update zyn. That interaction is a great example of a variety of things that are wrong with LMMS's development IMO and it certainly resulted in a lot of frustration for all parties involved.
Additionally, the lack of support for native linux VST/LV2 plugin support is a contributing factor for why I view the windows centric (due to the userbase bias) stuff irksome. (and if there was native linux VST/LV2, the whole zyn issue would have likely been avoided entirely).
@jasp00
some will not write at all.
I would argue that those are the individuals who's feedback you need the most.
We need data from developers that leave the project.
To be clear, I'm not pulling reasons out of thin air. I've spoken to LMMS developers, burnt out or not, frustrated or disappointed. I've been observing the dynamics of LMMS for years from the sidelines. Heck a year ago or so I read through all of the major threads on the linux-audio-dev mailing list (the whole darn history of it) to look at the problems causing people to leave with respect to the larger linux-audio community (for writing articles on the situation). Feel free to only accept quotes directly from ex-contributors, but what I've posted is a representation of what I've seen, been involved in, discussed, and heard directly from unnamed individuals.
@RebeccaDeField thanks for pointing out the chat logs for additional context
tresf
commented
7 years ago That interaction is a great example of a variety of things that are wrong with LMMS's development IMO and it certainly resulted in a lot of frustration for all parties involved.
Hmm... I feel the Windows portions of that Zyn 2.5 struggle were more of an example of how unintuitive it is to execute and load a remote process without a debugger... Which exposed the liability of having a Linux-only build system with a predominantly Windows user-base.
I still fail to see how Linux developers are "alienated" and I'm confused which tools you are referring to. I'm not trying to win an argument, but rather understand what this statement means. Until #3369 I've seen zero Windows developers contributing at all. Is this about RPCs? What setbacks do you see as a direct effect of Windows support?
tresf
commented
7 years ago To extend on the alienated users...
I could be wrong here, but my data shows we're really alienating the Windows developers.
According to a 2015 survey by stackoverflow...
</endrant>
On a somewhat related topic... aside from @curlymorphic's unofficial YouTube videos [1, 2], we don't even have an IDE configuration tutorial. I think a good getting-started guide would do wonders for gaining and maintaining contributors.
liushuyu
commented
7 years ago First of all, I think @fundamental has very thorough and unique views of this topic. IMO, he perfectly revealed every aspects of the problem.
As a relative new developer (maybe not a developer, more of a i18n manager :smile: ). I can tell several things that maybe useful to consider.
<aside>
Since Paul Batchelor has muted his notification, so I won't @ him to disturb him even more.
</aside>
Just as @jasp00 pointed out, our biggest enemy is time. Well, see I don't as much as active as before (like ~8 months ago, before I went to college). We are humans, we have our own works to do, and although we love LMMS, but limited by our abilities and time, we can't do pretty much about it.
If your guys are interested, you can try to dig out my comments before 8 months and now, you will notice my recent comments are generally shorter (except this one), harsher and much lagging behind . The reason is I don't have much time to write more and have more time to choose my words, because of the fact that I have tons of homework to deal with every day. (Maybe the same case as @jasp00 did before)
I have read through that contradict thread where all these things happened, I can see various opinions proposed by different people. Is there any hostile behaviors or comments? None IMO. But I guess (just guessing) the reason why Paul Batchelor regard some of them as "hostile behaviors" are:
My personal feelings regarding to this incident:
Undo button in our life. His leaving is a pain: we are in desperate need of good developers.staging branch and set this as default, all PRs target this branch, we'll merge the PRs if they are no harm to LMMS on the first sight, and review them later and periodically merge this branch back to master branch. Maybe this solution is too simple, but I've seen some other projects I participated in uses this trick.In the end, I would like to thank all the contributors and translators whether they are or were active, regardless of LMMS exists or not in this world, your valiant contributions are and will be remembered by everyone, forever. Meeting such community can be a fate that worth to cherish for the rest of yourl life. Thanks @tresf for your support of LMMS for so many years Thanks Vesa V, Tobybox, Diizy, curlymorphic giving birth to and raised the project Thanks @jasp00 for coming back to the project and help us out Thanks @BaraMGB for your hard GUI coding work Thanks @softrabbit @grejppi for many hard coding work Thanks @RebeccaDeField for your beautiful artworks, without you LMMS can't switch to new theme Thanks @fundamental for your continuous help to LMMS Thanks to all other contributors for all your work to make LMMS better
liushuyu
BaraMGB
commented
7 years ago I easily lose track of closed stuff
I lose track of needles in haystacks (570 bugs and growing). If people are only looking at open bugs, they >should go to the last page in my opinion. (if a bug has been open for that long we've needed for a long time).
I can't speak for the best way to manage so many issues without creating meta issues, which have been >working OK, but closing conversation threads at least separates them from the coding problems.
About our situation on github: we should consider open a dev forum on lmms.io and discuss there all the stuff. On github we could only allow real bugs (enhancement requests should handled in the dev forum) .
There is a further benefit from this : the development community and the user community come more together. And no more endless discussions on our bug tracker. Tbh I miss the mailing list. But it was a little bit cumbersome. Github is to static for discussions and we abuse it as development forum but it is a bug tracker.
On a dev forum on lmms.io people could ask about set up a development environment for example. Or qt or c++ specific stuff. We could help each other to learn how to code stuff for lmms. Sometimes I wished there were a place I could ask, for example, how playhandles works and such a stuff.
fundamental
commented
7 years ago @tresf I'd say the onboarding process for windows developers is a separate issue. To get new windows developers from what I've seen in other projects, essentially an IDE needs to have a very direct setup (i.e. all projects in source code management). Additionally, the IDE with the project needs to be the individual's preferred IDE (typically MSVC from what I've seen in other projects (though eclipse/qcreator appear relatively frequently)). While there are plenty of windows developers, very few of them (comparatively) appear to be interested in open source development (or even freeware development). So, I don't think the relative popularity of windows development matters much as it's the pool of possible contributors which is much more important.
When bringing up the consequences of the largely windows user base I'm not suggesting changing anything (or 'win' any argument), I'm just trying to note contributing factors for the discussion. Windows has a number of quirks with the file system, windowing system, etc which are non-intuitive to discover from the perspective of a linux dev (Qt hides some of this, but likely not all of this). (Additionally, comparatively supporting OSX is much easier to port to, though it does have it's own share of really dumb quirks). Supporting a platform without proper testing support adds frustration to any dev. The windows user base appears to attract many beginners looking for a cheap set of tools (i.e. $0) and these users appear to add significantly to the support load while contributing back comparatively infrequently. Overall the windows platform appears to slow down development/releases, but I may be vastly overstating the affect.
EDIT: I'll likely not add any followups to this issue as it has struck a nerve and will likely completely derail this discussion if delved into further.
tresf
commented
7 years ago While there are plenty of windows developers, very few of them (comparatively) appear to be interested in open source development
"Few" is a misleading word to use here because it's suggestive. A tiny percentage of the majority can still outnumber a large percent of the minority. It's a numbers game. Working professionally with development, this often isn't even a matter of preference, it's a matter of profession. If a developer is paid to work from a particular platform 8 hours a day, they tend to use that same platform during downtime, at home, for hobbyist projects, etc.
So, I don't think the relative popularity of windows development matters much
Although I cringe reading a statement like that, I suppose we'll know more once we offer it. Providing a reliable build environment has certainly helped for Mac developers as well as improved Clang-compiler support for platforms like BSD. Proving a direct correlation is hard, but I suppose time will tell.
typically MSVC from what I've seen in other projects (though eclipse/qcreator appear relatively frequently)
MSVC support would do wonders for the project, especially since VS 2015 began releasing a community edition for free, which is a very viable option. Unfortunately many of our tools are POSIX-based, so this transition will take a while. Dependency management is still an issue as well making rube-goldberg-esque problems/solutions. But QtCreator suffers identical problems (it predominantly supports/integrates/relies on MSVC++ when on Windows), so it suffers the same exact hurdles as VS. I don't know anyone that uses Eclipse for C++ development (I know many that use it for Android and Java), but if it makes sense to support, we may benefit in shifting efforts to that IDE.
I don't expect any developers to be vested in this task, but I really can't watch it being minimized without coming to it's defense. I work on teams with developers and setting up the environment and IDE is the first step we document for a project. The more platform agnostic the steps, the faster we have PRs.
The windows user base appears to attract many beginners looking for a cheap set of tools (i.e. $0) and these users appear to add significantly to the support load while contributing back comparatively infrequently. Overall the windows platform appears to slow down development/releases, but I may be vastly overstating the affect.
I've seen this same argument on the Pidgin mailing list as well as the Firefox mailing list. It may very well be a statistically accurate statement, but I'm not sure it carries any merit. Settings aside the fragmentation and learning curve of apps on *nix, in my experience recruiting developers, the proprietary desktops yield both the best AND the worst. Why? Well... so as long as employers, universities and high schools and off-the shelf-hardware are on a proprietary platform, that's where many good developers start. But I don't want to win an argument either, time is better spent following through on my side with the work to make this happen (and help is appreciated).
And finally... speaking a bit from personal experience... the transition to a Linux desktop can often be a long process as the professional grade tools one's replacing slowly reach stability and usability over time (as well as the hundreds of hours it takes to re-learn the replacement software). From what I've been reading on the chat logs, we have a strong community of very talented musicians that falls directly into this category (i.e. many of our top musicians reboot into Windows for mastering), so I come to their defense as well. ❤️ I know this starts to take the topic off-kilter, but since I can't yet help with the threading problems and I don't write plugins enough to know why wet/dry shouldn't go to -1, I can focus time on getting new people involved and I think platforms like Windows can (and do) have a positive effect.
The problem as originally stated... "keeping developers" still exists. Spending efforts on IDE integration as well as API/doxygen documentation is a good step in that direction, but I fail to see how Windows is part of the problem here and I think it's often used as a scapegoat.
Fastigium
commented
7 years ago The issue is why we lose developers
I'd also like to hear from @Fastigium
I'd be happy to comply, though I'm not sure how well my case generalizes to other lost developers. Let me start by saying that I still carry a torch for LMMS and the wonderful possibilities that it offers starting music producers. I have benefited from those possibilities myself, and have enjoyed watching others start to use it and grow as artists. I am deeply thankful for all the efforts people have put into the program over the years, and grateful for what I've been able to contribute.
The reason I stopped working on LMMS is because I burnt out while trying to fix #2457. Every time I dove deeper into the causes of the bug, I discovered more complicated problems with the audio code. It grew until it was too much for me. In hindsight, I should probably have explicitly requested other developers to help out a bit. At any rate, I lost motivation and around the same time got a programming job. Since then I haven't had the energy to program next to the job.
I did contribute to LMMS in a different way recently by initiating and doing most of the organizing work for the [Unofficial] LMMS Christmas Contest. Sadly, that ended up being kind of a letdown with only 5 submissions despite my promotion efforts 😞. I've actually considered stepping up as a judge for BoL v4, but concluded that the workload would be too heavy at the moment.
All in all, LMMS is still in my heart, and if I ever switch jobs I might return on the development side. For the near future, however, I don't expect that to happen. As for other ways of contributing, it's complicated. I'm in a long-time crisis period of my life now, and things go with ups and downs. Maybe during the next up 🙂
curlymorphic
commented
7 years ago I feel it would be more effective to simply contact those who have left and document in this thread.
Agreed,
My reasons were simple, new job, and burn out. The change in career and return to education after 23 years working on the tools, was hard work, fun, but very tiring. What little spare time I had I needed to find something with little to no stress involved, unfortunately, I was really stressed working on LMMS at that time.
The problem was I had hit a wall with the Zyn update, I had absolutely no clue how to solve it, yep the above-mentioned windows debugging. The author of Zyn @fundamental was an amazing help and guidance all the way through the process on Linux, but as a team, we simply lacked the experience to solve the problem on windows.
I had an amazing time while I was a contributor on the LMMS project, collaborated with many wonderful people, solved problems, probably caused a few, chatted on IRC, made some mates, learnt a lot of communication skills, programming skills, felt useful, and above all had fun. For this, i thank every person past and present on this project. If the time arises again that I find myself with a surplus of time, I would love to come back and contribute, however that moment is not in the foreseeable future.
tobydox
commented
7 years ago Same for me: lack of time due to fulltime job, partnership and additional work as a freelancer for one of my other FOSS projects. I'm however glad "my baby" LMMS is still alive and such an active community has grown! At the same time I'm absolutely ashamed of having left this horrible core and architecture to my successors even though things already improved slightly with the model-view-split many years ago. I started the project at the age of 16 in a very pragmatic way of thinking with just about 3-4 years of programming experiences back in 2004. 13 years later I would start all over again and rewrite many if not most parts of the program if I had the time. I'd like to encourage active developers to do so right now. While doing so you should enforce an even stricter separation of audio processing, models/data and views and take advantage of modern C++ features. I'd also think about rewriting the UI using QML/Qt Quick and keep the focus on both traditional and touch usage. Tablets could be a perfect additional target platform. I fear LMMS will die sooner or later without a radical change :-(
jasp00
commented
7 years ago The open/closed status is arbitrary.
Then, since I leverage this status, do you mind if I set as I need?
we should consider open a dev forum on lmms.io [...] On github we could only allow real bugs
GitHub is the place for developers (accounts, contributions, etc.) and this issue is about how to handle developers. LMMS is a GitHub organization and organizations discuss human resources. This issue does not infringe content restriction terms. However, you may want to handle organizational issues in a separate repository.
To be clear, I'm not pulling reasons out of thin air.
I did not say that, @fundamental, although you state "from my likely flawed observations". We cannot solve every cause in the Linux audio community, we need to focus on this project. As far as I see, our main reasons are:
We should handle each reason in separate issues.
Instead of keeping a wiki page with testimonies, I propose we maintain a meta issue with a list of developers that we could bring back given enough technical and economic resources. Each developer case should be an issue.
So, @Fastigium (assuming you can talk about this in the tracker), if we were able to take care of your economic needs someday, would you come back to LMMS?
tresf
commented
7 years ago Then, since I leverage this status, do you mind if I set as I need?
Sure, as long as you're also OK with a developer arbitrarily closing this out in 18 months when it's still open.
jasp00
commented
7 years ago Sure, as long as you're also OK with a developer arbitrarily closing this out in 18 months when it's still open.
No problem.
Fastigium
commented
7 years ago So, @Fastigium (assuming you can talk about this in the tracker), if we were able to take care of your economic needs someday, would you come back to LMMS?
A very interesting thought experiment! The short answer is that I might, but that I don't think I'm the right candidate.
Let me clarify: I'm good at hunting causes of bugs. It's something I like to indulge in much like solving a sudoku puzzle. When it comes to other work expected of a developer, I fall short. I barely have any background in audio/DSP programming, or in programming desktop applications, or in managing big programming projects. My work experience has been in small-scale web programming, mostly in PHP. I would either have to invest lots of time in learning before I start working, or learn as I go and make lots of rookie mistakes. Neither sounds particularly desirable to me.
If there were a lead developer with sufficient experience, that would be better. I'm a quick learner, and (s)he could help me avoid rookie mistakes as I go. Still, I'm not sure if it'd really work for me. I've learned that I like working at an office, with colleagues actually around, being able to talk face to face. I'm not sure developing from home would work for me in the long term.
jasp00
commented
7 years ago Even if @tresf did not mention you, we cannot discard any manpower.
If there were a lead developer with sufficient experience, that would be better.
So we need a guide for you, that is feasible.
I've learned that I like working at an office, with colleagues actually around, being able to talk face to face.
Ask them if they would like to do some team work on a particular feature, such as a plug-in written in PHP, a web status monitor, an Ajax interface, etc.
musikBear
commented
7 years ago Ive just throw my -5 € in the conversation Creativeness is not seldom connected to a sense of 'pride' I have worked with people that were certified as genius. Some have been more 'fragile' than eggs in vinegar.. some times this 'fragility' comes out in text as significantly harsher than it was meant. The keyword is in text! Communication in text is quite an art. This has indeed had historical consequences, war has happened.. The expression and the tone of the voice is extremely important in order to understand the whole message as the 'sender' intended the message. That is not possible on a bulletin board! That leads to a part-conclusion: When communicating on a bulletin board, wordings should be considered and perhaps not posted emediately, especially if the post contain points of critique or is meant to disregard an other persons idea or input. Here it is best to let the post 'rest' a bit, look it over, and make sure it does not come out in a aggressive or insulting way. Supportive posts does not ned that second look :) That s my personal pov on the issue of alienating volunteers in the project. I do however also believe, that the very project itself, may appear to daunting, for some. My thoughts here are the structure of the project itself, or rather the lack of structure. I have to think more about it :)
jasp00
commented
7 years ago Supportive posts does not ned that second look :)
I recommend that you review supportive posts too. Recipient may feel your message is not supportive. You should be careful on first-time communications and with people from other cultures.
Fastigium
commented
7 years ago Even if @tresf did not mention you, we cannot discard any manpower.
Granted. My argument was more along the lines of "if you're going to shell out money for a developer, there are probably better candidates than me".
Ask them if they would like to do some team work on a particular feature, such as a plug-in written in PHP, a web status monitor, an Ajax interface, etc.
I'm not really sure what you mean with that. If you mean "ask your colleagues to work with you on LMMS within the parameters of their experience", I don't think they have the time. Like me, they don't program outside working hours, and our boss keeps us plenty busy within them 🙂
jasp00
commented
7 years ago Like me, they don't program outside working hours, and our boss keeps us plenty busy within them
Programming for LMMS is a learning experience and it is fun. Working as a team in a free software project may strengthen group skills and friendship. Even your boss may be interested and give you some spare time. LMMS 1.1.3 has more than 1.6 million downloads. An online interface would show your company's abilities and we could add a "Try it online" link in the homepage.
A little research shows that sites offering "LMMS online" do not work, so you will be the first ones. Other online DAWs (Audiotool) do not guarantee that software will be available if the site goes down, so your solution may have a differential advantage.
Just ask them. Asking does not hurt, right?
Fastigium
commented
7 years ago @jasp00 While I admire the audacity and creativity of that plan, I don't think it's feasible. It's not in my company's niche, we have enough actually paying work to do and over a dozen more advantageous projects lying in wait for any lulls in the workload.
Also, I don't think it is what LMMS needs right now. Getting the core issues ironed out seems much more important to me than adding a web interface.
jasp00
commented
7 years ago It's not in my company's niche
Do you work with HTML5 audio, Web Audio, or Flash?
we have enough actually paying work to do and over a dozen more advantageous projects lying in wait for any lulls in the workload.
I am sure, but entrepreneurs love business opportunities and advertising. Is your company's profit over 1000 million dollars? If not, you should ask your boss (unless you have an explicit "no free software" policy). Managers like to study these cases and you show that you care for the company's success.
Just send a short message ("Sorry to disturb you,") with a link to https://github.com/LMMS/lmms/issues/3447#issuecomment-290047167 and saying that you believe this could benefit your company. Your boss may ignore the message, or get interested and do some numbers. I am sure your boss will appreciate your trust and goodwill in sending this message.
Getting the core issues ironed out seems much more important to me than adding a web interface.
We can do both. Let the core issues to us.
tresf
commented
7 years ago If the objective is to yield commercially sponsored help, it may make more sense to go after an industry that needs LMMS to survive, such as education or a media company that has deep FOSS roots.
Many FOSS projects are backed by industry for these very reasons. For example, Walmart openly admits to using and contributing heavily to Node.js. EMC/Dell have state of the art infrastructure running on OpenStack. These tools attract end-users that are often already in the IT field, so perhaps they're bad examples.
Our lobbying efforts may be better spent bugging developers in the education sector. AFAIK, @unfa has used LMMS in the education sector. LMMS adoption by an arts college (by both developers and aspiring artists) may be a step in a better direction. Singling out @Fastigium is a bit unfair, I think... 😕
jasp00
commented
7 years ago If the objective is to yield commercially sponsored help
That is a completely different issue. The problem right now is how to gain back our developers. This is solved by studying each case, one by one, until we succeed or identify the cause that we cannot remedy.
Singling out @Fastigium is a bit unfair
This is our first random case. However, I am not targeting @Fastigium only, but his whole team. To accomplish this, I need to make him understand the advantage of my proposal, because he is probably afraid of risking his job, right? Bosses are not ogres (many of them are not); they like to have their subordinates' trust.
tresf
commented
7 years ago That is a completely different issue.
No, it describes exactly what is happening.
I am not targeting @Fastigium only, but his whole team.
That is exactly targeting. Using buckshot doesn't change what you're shooting at.
To accomplish this, I need to make him understand the advantage of my proposal [...] he is probably afraid of risking his job
I'm not even sure how to respond to this statement. It seems to be written in an overbearing yet naive tone. The proposal is quite unrealistic.
In some ways I enjoy the proposal on it's own and I think we need more, but it's just an idea. I fail to see the benefit in targeting this idea. It seems like it has a better home in a suggestion box.
jasp00
commented
7 years ago No, it describes exactly what is happening.
Could you explain your view? The objective is not to yield commercially sponsored help; the objective is to have @Fastigium back. In order to come back, @Fastigium's needs are to work with his colleagues and to have some spare time from his job. To get spare time, we have to provide his boss with a proposal that would benefit the company; there are some possibilities, the online interface is one.
That is exactly targeting. Using buckshot doesn't change what you're shooting at.
Please, do not talk like I am pointing with a gun. "To target someone" means to have someone as intended audience; I would like @Fastigium's team to work on LMMS because it is educational and fun, or is it just my viewpoint?
The proposal is quite unrealistic.
What is unrealistic? An online interface?
It seems like it has a better home in a suggestion box.
This is my point. @Fastigium, use the suggestion box for employees.
Umcaruje
commented
7 years ago The objective is not to yield commercially sponsored help; the objective is to have @Fastigium back. In order to come back, @Fastigium's needs are to work with his colleagues and to have some spare time from his job. To get spare time, we have to provide his boss with a proposal that would benefit the company; there are some possibilities, the online interface is one.
That isn't how this should work imo. We can't force people back to LMMS. We should make changes in the documentation and other places as previously discussed here to attract new devs and make new devs more welcome in the codebase.
Making a U turn and just changing the direction of the project to web audio while the core/GUI needs serious work is just unrealistic, as @tresf said.
Having a company/school work on LMMS would be amazing, but they should work on it for what it is: A Free, Open source, offline DAW, that has major issues in it's core and poor audio editing and non-existent audio recording features.
I don't believe the project's scope should change just to accommodate for a lost developer.
jasp00
commented
7 years ago We can't force people back to LMMS.
No one is forcing people back, the same as no one is forcing people to stay; we are volunteers. I am just asking what a developer would need to come back and see if we can remedy that.
We should make changes in the documentation and other places as previously discussed here to attract new devs and make new devs more welcome in the codebase.
Again, that is a completely different issue. The problem right now is how to gain back our developers, not how to attract new ones.
Making a U turn and just changing the direction of the project to web audio while the core/GUI needs serious work is just unrealistic, as @tresf said.
No one is changing the direction of the project. This is the beauty of model/view split, you can have a Qt interface, an ncurses one, braille, web, etc. Whether the core/GUI needs serious work is irrelevant to this fact.
A Free, Open source, offline DAW
There will always be an offline interface, but why cannot there be an online one? Why must we discard web developers?
Fastigium
commented
7 years ago @jasp00 If your goal is to get me to come back as a programmer, please read the next lines carefully. I do, indeed, feel targeted by your persistence in arguing that I should somehow get my colleagues to work with me on LMMS. You probably mean well, but you're driving me away. Please let the idea rest, at least with regards to me.
To everyone: thanks for the ❤️ reactions to my first post in this thread. I wish there was more that I could do. Thanks for your support 😌
oeai
commented
7 years ago hello! well i'm not a programmer, in fact i'm economist, i was contributing with translation. Dunno why just today i've opened this thread among all others i got and maybe i'm wrong, but i feel like there's a lack of motivation (and lack of time). When i was programming some little tools, for me it was necessary to get user feedback to know that they are using it. LMMS is used around the globe i guess, but there are alternatives and well it's a music making suite, not a car driving AI. So for a motivation sometimes money works or some kind of meeting, conversation or vacations as a part of team - building, that's my guess it's not obligatory. For conversations you can use google\skype metting like a dev-code-review. For meeting you need some bunch of money to get somewhere together and to get some money maybe you need something more than donations. And as economist i'd propose to write some "official" 1-5$ paid plugin for example to support ASIO or better support for VST (i got problems with). But well i'm not a best paid user, i'm working for free on some complicated issues and just sometimes i'm writing music and being developer is maybe a harder thing, that i don't like to do really. As a programmer usually i am trying to solve some particular problem, not just everything and my rest-vacations are very long, but i'm doing something else beside and if i see i can make a better code + i feel that it will be important, then i can get back to work. So i think that it's a normal thing when you need to do something else and maybe later get back in. oh and btw just today i've wrote a tiny melody with lmms. thx
musikBear
commented
7 years ago All i want to add, is a big thankyou for the work @Fastigium @curlymorphic @diizy and ofcause @tobydox (lovely to see you post btw :) and all others has done to this project, wheater they have left or just having an extended 'vacation' from the project :) 🍾
..And also -maby ..a thread about why the LMMS-project looses participators, should be kept in a civilized way/ language ? It would be kind of nemesistic if this exact thread, alienated someone from the project, right? :)
jasp00
commented
7 years ago I do, indeed, feel targeted by your persistence in arguing that I should somehow get my colleagues to work with me on LMMS.
You should not somehow get your colleagues to work with you on LMMS. You say that you like to work with them and talk to them face to face. So, why not to ask them to join the party? Have you tried to ask just one of them? The one you are most confident with? I only say that you should make a question, this is something totally voluntary.
But if you do not try, that will mean it is your own decision; there will be nothing we can do to bring you back. We can break economic and technical barriers, but we cannot break a personal choice.
I wish there was more that I could do.
There is and it is entirely up to you.
fundamental
commented
7 years ago Goodness, @jasp00 you're barking up the wrong tree and you don't appear to know when to stop.
tresf
commented
7 years ago Have you tried to ask just one of them?
To redirect the ad hominem and take the good from this proposal... Yes, I've done this on several occasions. Most of my colleagues just don't care about music production enough so there's not a whole lot of incentive.
My organization is predominantly proprietary but we're slowly adapting FOSS where possible.
The incentive to work on these projects usually comes from a direct business need, so recruitment to LMMS has been unsuccessful in my attempts. (I'm in the insurance/financial services sector, which doesn't do much creatively aside from basic audio editing and a few graphic needs)
What seems to help out the most is improving our developer documentation as well as platform support (e.g. Fedora, Debian, OpenSUSE, FreeBSD, Mac, Win). But this will still only attract one-off PRs I feel. Getting a good core developer involved is just a lucky coincidence at this point, I feel. <3
Spekular
commented
7 years ago @jasp00 imo, "should" doesn't sound much like an offer. I wouldn't quite call it a command, but it's more towards that than a request, I'd say.
I also agree with the others that your method isn't the best way to get developers back, and I think it might even drive some away.
All that being said I'm certain you have good intentions.
jasp00
commented
7 years ago I wouldn't quite call it a command, but it's more towards that than a request, I'd say.
It is a command from oneself if one wants to be coherent. I just make people aware of it.
I also agree with the others that your method isn't the best way to get developers back
Then teach me. Let me see how you do it.
Another discussion point per http://www.pbat.ch/blog/posts/2017-03-18-lmms-part2.html.
Although I too get burnt out by the project, I wonder if something could have been done better here. 😕