Why do we keep losing good developers? #3447
Comments
|
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 :/) |
|
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. |
|
@tresf, please reopen, this issue is important and we are not done. Thanks for contextual links. @PaulBatchelor case
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 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
|
|
@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.
***@***.*** <https://github.com/PaulBatchelor> case*
First, let us see this case. The blog post is harsher than what you
quoted. What has happened?
-
#3412 <#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 <#3422>, "correcting an
accidental 10-year old bug". AFAIK, this is an intentional feature and I
have stated
<#3422 (comment)> how to
proceed. The issue is still open and I think our feedback is correct.
-
#3404 <#3404>, "fixing the
command-line renderer". I have suggested
<#3404 (comment)> 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 <#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
<#3416 (comment)> 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
<#3447 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ADlPbizSpHgOiqwGZ1Njcfb68HvJQIXlks5rn-17gaJpZM4MjQqU>
.
|
|
I've unsubscribed from this feed, and I've been only gleaming over the comments getting the gist of things. A few additional thoughts:
|
I've created a new This thread is still open for discussion.
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...)
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.
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.
I tend to agree holistically, but it's a hard road getting there. |
|
@PaulBatchelor In case you skim the thread later on: For the record I agree with the general opinion on LMMS's codebase:
@jasp00 re:
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. |
|
@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. |
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. |
|
The only statement from @fundamental I disagree with is this one...
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) |
We are human, @PaulBatchelor. Get over it and come back.
@tresf, I easily lose track of closed stuff. May I open a separate issue to handle my proposal?
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.
@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.
@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? |
@jasp00 he already did. EDIT: If you're not already on discord you might want to read over the logs in #devtalk. |
I see. |
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 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.
I think there's a slight bit of perceived/unintended rashness in statements like this. :) <3 |
|
@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).
I would argue that those are the individuals who's feedback you need the most.
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 |
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? |
|
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...
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. |
|
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 😄 ). I can tell several things that maybe useful to consider.
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
My personal feelings regarding to this incident:
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. liushuyu |
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. |
|
@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. |
"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.
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.
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.
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 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. |
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 🙂 |
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. |
|
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 :-( |
Then, since I leverage this status, do you mind if I set as I need?
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.
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? |
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.
There is and it is entirely up to you. |
|
Goodness, @jasp00 you're barking up the wrong tree and you don't appear to know when to stop. |
To redirect the 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 |
|
@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. |
It is a command from oneself if one wants to be coherent. I just make people aware of it.
Then teach me. Let me see how you do it. |
|
@jasp00 Fastigium him/herself said they're not the best candidate & they didn't think they'd work well home alone. At this point I would have left it. You asked if they could potentially work on it with their coworkers (a fair question, that would be one solution) and Fastigium responded that they probably couldn't. At this point, going further seems desperate and pushy, especially when your posts from then on only seemed to reiterate "ask your coworkers". Not everyone will want to work on LMMS full time. We should try to find a better candidate who is interested, rather than trying to convince someone who isn't. |
They probably could too, we do not know for sure, but there is one way to know.
No one is requested to do that.
Which is my point, we cannot break a personal choice. Now, could you try to bring back someone who is interested? |
|
I think we can all agree that there are a lot of variables that come into play here, and there is not one "magic" answer to why we lose devs or how to attract more. A lot of great ideas have been discussed and a lot of good points have been brought up. If we want to see these ideas become a reality, read over the list, find what you can do to help and put it into action :) I see that @jasp00 has only the best intentions ❤️, but I think it might be a good idea to let that particular conversation with fundimental rest now. I don't think that debating each other about what people should have or could have done better in that situation will lend itself to much progress at this point. |
|
Here's someone asking to get involved right now. https://lmms.io/forum/viewtopic.php?f=4&t=8484&p=29236#p29236 @musikBear I understand you're trying to establish some form of "Welcome, read the rules" greeting/disclaimer, but please take a minute to step back and look at what you're doing. Let's not kill people with lectures as soon as they offer help. Save lectures for the offenders. That said, this guy wants to get started and linking him our Compilation tutorials and our discord channel are probably the best start. Currently, the |
Understood -I was only trying to avoid a new situation like the one with 'no-name-mentioned' bothering this place and mostly you to the level where you banned him from writing more here. If you remember. |
|
Now that I've thought some more on the subject, I'm getting curious how FOSS developers with a job manage to do it. I mean, curlymorphic, tobydox and I all list having jobs as reason not to develop for LMMS anymore. @fundamental May I pick your brain about this? You appear to have amassed some knowledge on the coming and going of FOSS developers 🙂, would you know how this is generally done? Anyone else with knowledge on the subject, feel free to chime in. |
Update: @Spekular has created |
Great, this user is welcome, but you are eluding the problem: how can we get back LMMS developers? If none of them are interested, no matter what we do on our side, then we can do nothing about it. I have tried one random case, the next one should follow; they know how to step forward.
This is the same problem as developers with a family and countless commitments. One week has 168 hours, you manage your time as you see fit. Working on a project that you like is a rest compared to a mandatory job; you may dedicate some TV time to FOSS development. Going part time or getting yourself temporarily fired might get you some time (assuming this is an option). Family may help with chores. The best part of many FOSS projects is that you do not have a work schedule like in a traditional job. You do not need to ask for permission to go on leave. You dedicate as much time as you want: 5 hours per week, 2 hours per month, 8 hours in August, etc. You may think of it as $10 donations. If you like to fix bugs, you may choose one open issue, work on it one afternoon, and resume next week; communication is important. If you fix the issue, you are done. If you grow tired, you should say so and stop. |
|
Sorry, @jasp00 this
I would say no. |
Well, at least I am talking for myself. Ten years ago I was a full time programmer for proprietary software and I was coding for LMMS and other FOSS projects too. I am convinced I am not the only case in the world.
@musikBear, the answer to that question is no. The causes have been identified. Formally, the main reason is the lack of time because of a job, but in one case it has been proved it is not the real cause. We do not require full time commitment, yet contributions from former developers seem impossible. We get some feedback, which is greatly appreciated because at least we know where the problem is, but this does not fix issues. We should act on real data rather than guesses, on "what is" instead of "what if". There is not much left to discuss, unless a former developer explains what could be done to possibly rejoin. |
|
On 03-31, Fastigium wrote:
Now that I've thought some more on the subject, I'm getting curious
how FOSS developers with a job manage to do it. I mean, curlymorphic,
tobydox and I all list having jobs as reason not to develop for LMMS
anymore. @fundamental May I pick your brain about this?
Sure. I'll add another disclaimer upfront as many individuals don't
specify their day job obligations, so information is much more sparse
compared to "I'm leaving due to X" style rants.
My general interpretation is below with regards to linux-audio, but take
it with a hefty grain of salt.
You appear to have amassed some knowledge on the coming and going of FOSS developers ????,
would you know how this is generally done?
From what I've seen (on a broad scale) many simply do not.
One fairly normal trend to see within linux audio (and presumably
other FLOSS areas) is individuals new to various software development
issues appear wanting to learn and help (college aged
individuals seem to be a frequent component, though not necessarily a dominate one).
Over a time period 2-4 years they may be active contributors and then a
change in their life happens (e.g. moving from academia to employment,
job change, etc).
The change can result in many fewer hours being freely given to open
source work or stepping back from the community entirely.
Typically if someone transitions into a position where they are working
on software full time, then they tend to be much less interested in
working on software in their free time [1].
There is no one size fits all for this hobby, as there certainly are
individuals who work full time in a related field, though once you add on
those constraints you tend to end up with more logistical difficulties
collaborating with individuals.
In linux-audio I'd say that these developers are more likely to work on
projects that are smaller/more independent resulting in standalone
projects with a higher chance of being abandoned in the future.
Additionally, it is very difficult for companies to justify investing
resources into linux-audio tools as it's a niche market and very few of
them stand to directly gain from improvements made to any of the linux
audio tools (though exceptions exist here as well).
For a brief digression, let's look at a bit of data which backs up the
idea that many people are time/energy limited most of the year.
One figure that I was looking at while writing up this rough impression
of what happens I was reviewing on figure from [2].
Over the years a cyclical trend with a period around a year can be
observed in the number of posters on mailing lists like LAD.
Zooming in on one section results in [3].
I originally thought that the trend indicated a link to the academic
year, but it may simply be some end of the year downtime as there seems
to have been elevated numbers of posters around December/January.
This to me hints that there are people that want to contribute more,
but are simply limited by time/energy most of the year.
Hopefully that ramble was interesting and/or helpful in some way.
Anyone else with knowledge on the subject, feel free to chime in.
+1 for that. Understanding the demographics, structure, and dynamics of
the community are very important for the future IMO.
I do find the declining levels of engagement (and likely development) in
the broader linux-audio community to be concerning [2].
If possible I would like to help bring introduce new developers and help
retain existing developers. At the end of the day though, there's only so
many hours and so much energy.
[1] - General news.ycombinator.com discussions on jobs+open
source+work/life balance
[2] - Linux Audio Slowdown http://log.fundamental-code.com/2016/01/22/linux-audio-slowdown.html
[3] - http://fundamental-code.com/tmp/2002-2016-la-authors-yearly-trend.png
|
|
Hi all, My point is: do not feel bad because of lack of contributors or contributors leaving. |
|
Taking care at #3480. |
|
@fundamental Wow, thanks for the detailed and thorough analysis 👍. Food for thought, and I recognize myself in many aspects of your interpretation. Helps me see things in perspective. @midi-pascal Thanks for sharing your view as well. It all gives me a lot to think about. I need to let this stew for a while. Glad to hear there's someone else who loves LMMS and wishes he could contribute more ❤️ |
|
Following comments from #3480,
May I remind you of #2745? LMMS is in the business of features. To get new ones and fix current problems, we need qualified developers. If you are not interested in former contributors, could you let me handle those who actually want to return?
No, I would like people to tell us which obstacle prevents them to contribute. #3480 lists pending cases.
I am going after past developers that formally express they want to come back. Contributors control their level of exposure and our ability to help them.
The question has been answered:
On what evidence do you base that statement?
Agreed, but unrelated.
If recruitment includes former contributors, I agree. However, your suggestions ignore the real problem: spare time and jobs. You can attract one million college students and, when they become most productive, all of them leave because they need to pay bills. We need to keep our investment. Do you want LMMS to be an amateur product eternally or do you want to reach professional grade? |
|
First, I'll preface my statement with a satirically polite:
Please screw off with that glittering generality bullshit. ❤️ LMMS already is professional grade for many musicians and getting strong developers is only a piece of that puzzle. Branding, stability and modern availability are a huge part of a product's success. We have to be careful not to over-manage the unmanageable, or the impractical. So let's call a spade a spade before we start. LMMS is doing pretty well in it's amateur phase.
Well, that or... because they've scratched the itch, or they've become burned out. Human problems can't always be fixed with simple logic because human factors aren't always visible or tangible. For example, when someone says
Two have told me this when I contact them personally. Not all of them have left though, so you can weigh this as you will, but you may have to just take our word for it: 1, 2, 3
Ah... Well, now I finally like where you're going with this. If we're talking about the elephant in the room, let's just talk about it and not beat around the 🐘 bush. |
So where we are? What is our perception about current state of LMMS? Professional or amateur?
Then let us not discard that piece and discuss how to fit it.
Right, do you mind if a handle the visible and tangible cases first?
We do not have to. People that want to come back will tell us what their real problem is. @Fastigium's case has not worked because she does not really want to return.
I will. Documentation is necessary, but until a developer formally states that she cannot contribute in any manner because of our documentation, it should not be a priority regarding former developers.
Fine. The goal is to have features and fix bugs faster, so we need more developers. If their problem is economic, crowdfunding may be the solution. Let us wait until a case arises in #3480. |
|
I've decided not to respond to this thread any further. It is not constructive use of my time and it's stressing the fuck out of me. |
|
Questions are welcome. |
I don't think anyone has any more questions, but since you're taking a binary approach at this problem, here we go...
Probably not, but we can leave that for the dedicated topic you've created #3480.
Crowdfunding a project as large as LMMS has some serious implications as illustrated in #2745, but the most important being organization of it all. I too think this is in our future and there may be some moments in the past where compensation would have been the difference between keeping and losing a developer, but this model has not yet been put into place, so it's relevance is always going to be speculative -- even by those you ask. Payment assumes some things, such as strong leadership, vision and direction (i.e. if not, who determines these things?). Our developers are struggling to offer that leadership and guidance now and we've clearly struggled with this holistically for many years.
Agreed, but only by consequence. It is true... former developers are already familiar with our codebase and the documentation is less likely to help. But I'm going to take a sharp turn and bring this back on topic... Why we lose them. The repeat mention shouldn't be ignored. Onboarding a new developer takes weeks (not hours). Good documentation can cut this time in half or even better; but creating the documentation takes a very long time too and it is rarely done well. In lieu of this, I'm outsourcing the IDE work in #3483 to @Vzor-. I've worked with him on previous projects. On a personal note, he's my step-brother so I know him personally. On a professional note, he brings with him a strong background of OSs and programming languages. He's debugged DBUS, Gtk2/3, he's familiar with several commercial and free IDEs and he's collaborated on teams much like ours before. For now, he'll only be doing #3483. I'll be compensating him for his time. Please welcome him to the team. I'll be funding this with my own money. |
|
Thank you. I look forward to working with everyone here! |
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. 😕
The text was updated successfully, but these errors were encountered: