search

LMMS / lmms

Cross-platform music production software
https://lmms.io
GNU General Public License v2.0
7.93k stars 993 forks source link

Why do we keep losing good developers? #3447

Closed tresf closed 7 years ago

tresf commented 7 years ago

Another discussion point per http://www.pbat.ch/blog/posts/2017-03-18-lmms-part2.html.

From @PaulBatchelor Goodbye, LMMS

I began writing an outline of this post last week. I had very exciting (and perhaps naive) ambitions for what LMMS was going to be in my life. And I do have some some interesting I built that I want to talk about.

But if I'm going to be honest, I'm done contributing things to LMMS. I really don't have the stomach for dealing with some of it's users, who are rude and hostile towards any of the contributions I have to make. And I just don't have time for it. Let me list the things I got chewed up on:

  • changing specific files to MIT license for easier plugin development #3412
  • Correcting a 10-year old bug which accidently was changed to have negative vaules instead of all positive ones #3422
  • Fixing the command-line renderer so it doesn't glitch randomly #3404
  • Suggesting the removal of worker threads for audio processing #3416 [...]*

* Content truncated, added links for contextual info

Although I too get burnt out by the project, I wonder if something could have been done better here. 😕

Spekular commented 7 years ago

@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.

jasp00 commented 7 years ago

they probably couldn't.

They probably could too, we do not know for sure, but there is one way to know.

Not everyone will want to work on LMMS full time.

No one is requested to do that.

rather than trying to convince someone who isn't.

Which is my point, we cannot break a personal choice. Now, could you try to bring back someone who is interested?

RebeccaDeField commented 7 years ago

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 :heart:, 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.

tresf commented 7 years ago

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 #devtalk channel isn't open to the public. I recommend we rename it to #admins and make a new #devtalk thread specifically for asking build questions, open to the public. I'd subscribe to this channel. Consider that a formal request @StakeoutPunch. I can file a bug report on the .io repo if needed.

musikBear commented 7 years ago

Let's not kill people with lectures as soon as they offer help. Save lectures for the offenders.

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. I just wasent sure about his cpp knowledge, so asking him to read code, seamed like a sane idea

Fastigium commented 7 years ago

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.

tresf commented 7 years ago

Currently, the #devtalk channel isn't open to the public. I recommend we rename it to #admins and make a new #devtalk thread specifically for asking build questions, open to the public. I'd subscribe to this channel. Consider that a formal request @StakeoutPunch. I can file a bug report on the .io repo if needed.

Update: @Spekular has created #open_devtalk on discord for this.

jasp00 commented 7 years ago

Here's someone asking to get involved right now.

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.

I'm getting curious how FOSS developers with a job manage to do it.

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.

musikBear commented 7 years ago

Sorry, @jasp00 this

Working on a project that you like is a rest compared to a mandatory job

I would say no. If you have been coding all day, and are bound to code again tomorrow, then i honestly doubt, that a 'rest' with coding will be the first thing in your mind. But imo the discussion miss its target. The gist is: does the project itself, that being either the 'culture' in the group, or the complexity/ structure of the actual code, lead to people leaving the project Everything outside that scope, is not in the groups control. Our culture and project structure is There for that should be the focus point, if indeed either is influencing peoples decision to be part of the project. This discussion should focus on that if

jasp00 commented 7 years ago

If you have been coding all day, and are bound to code again tomorrow, then i honestly doubt, that a 'rest' with coding will be the first thing in your mind.

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.

does the project itself, that being either the 'culture' in the group, or the complexity/ structure of the actual code, lead to people leaving the project

@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.

fundamental commented 7 years ago

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

midi-pascal commented 7 years ago

Hi all, I would like to express my view on this topic. Perhaps I am not a typical contributor to LMMS because I contributed (very) sporadically in the passed 5 years. I love LMMS, use it and do not want it to ever disappear. In the passed years i solved some bugs and contributed to the French translation with pleasure and enjoyed the great help from @tresf and others LMMS masters to make my fixes the right way and never felt spoiled or assaulted in any way, never. I am an old programmer (57) and now I work for the most famous sound engine for video games so my free time is sparse. I contributed the most to LMMS while I had no job. I am still reading lmm-users and lmms-dev posts with great interest. I would like to contribute again to LMMS more actively but I feel like I cannot be very effective because of this lack of free time so solving a single simple bug could take a while.

My point is: do not feel bad because of lack of contributors or contributors leaving. LMMS is a great software and even with its flaws, many many people use it love it as it is and enjoy it.

jasp00 commented 7 years ago

Taking care at #3480.

Fastigium commented 7 years ago

@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 ❤️

jasp00 commented 7 years ago

Following comments from #3480,

Now LMMS is in the business of fixing personal/employment/bandwidth problems? No.

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?

he wants each fallen soldier to write a testimonial in a separate bug report that we can cross-link to fix the problem as a whole.

No, I would like people to tell us which obstacle prevents them to contribute. #3480 lists pending cases.

I don't know if going after past developers helps at all, it will only add unnecessary exposure to the developers.

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 was WHY WE LOSE THEM

The question has been answered:

and a bit part of that is lack of core documentation

On what evidence do you base that statement?

We need a place to send new developers and we need a way for them to know which tasks are good to start working on.

Agreed, but unrelated.

So a solid recruitment strategy is part of the big picture of keeping developers.

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?

tresf commented 7 years ago

First, I'll preface my statement with a satirically polite:

Do you want LMMS to [...] reach professional grade [or be an] amateur product eternally

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.

You can attract one million college students and, when they become most productive, all of them leave because they need to pay bills.

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 a job, one person may consider that a financial obstacle, whereas other may view this as a combination of career|morale|healthcare|retirement|job security. We shouldn't minimize the human complexity with a logic gate.

On what evidence do you base [the] statement "part of [losing developers] is lack of core documentation"

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

May I remind you of #2745?

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.

jasp00 commented 7 years ago

LMMS already is professional grade for many musicians [...] LMMS is doing pretty well in it's amateur phase.

So where we are? What is our perception about current state of LMMS? Professional or amateur?

getting strong developers is only a piece of that puzzle

Then let us not discard that piece and discuss how to fit it.

human factors aren't always visible or tangible

Right, do you mind if a handle the visible and tangible cases first?

We shouldn't minimize the human complexity with a logic gate.

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.

lack of core documentation

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

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.

If we're talking about the elephant in the room, let's just talk about it

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.

tresf commented 7 years ago

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.

jasp00 commented 7 years ago

Questions are welcome.

tresf commented 7 years ago

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...

People that want to come back will tell us what their real problem is.

Probably not, but we can leave that for the dedicated topic you've created #3480.

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.

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.

documentation [...] should not be a priority regarding former developers.

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.

jasp00 commented 7 years ago

Please welcome him to the team. I'll be funding this with my own money.

If we like the result, he is a candidate for #3480. Welcome, @Vzor-.

Vzor- commented 7 years ago

Thank you. I look forward to working with everyone here!