How do I be more productive in open source projects?
June 16, 2024 5:05 PM Subscribe
I'm retired (laid off) and found some great open source projects, It has me really passionate about programming after years of climbing the ladder. I am really enjoying doing it but sometimes either my talk gets too corporate (lets focus on not making it prove the user understands this) to simply it got me out of corporate thinking of how can I just get things done without large vendors and a lot of stupid meetings. I'm not gelling well with these type of developers and it might be my corporate side coming out. I'm not looking to make money but they're really focused on minutia and I'm more of a big thinker. Suggestions on integrating with the communities?
It seems like open source programmers are smart people who get stuff done. I've dealt with large, large companies and explain sometimes oh yes "big giant company X does it this way" it works out well but it requires some structure.
Recently retired I'm a bit cast down seeing two great projects and maybe getting into executive, management talk when describing things and I think they just want concrete answers. I really love being in a smart community but I won't commit code without testing or sticking to some basic standards, If they can get something done but it won't install correctly the theme seems to be like "oh well figure out how to uninstall it."
I also explain how large SV companies FAANG or whatever do things at a high level and how effective it s to achieve their goals. From an executive level to an engineering level, They simply dismiss the argument based on it is how Google does it and working with large multi-nationals they do stupid politics and smart engineering.
Like they seem to want to make things hard or I do not know what I'm talking about. They don't think of the end user and how people don't like digging through source code. I'm really depressed, I looked at it like woodworking, I can program but it is hard for me to program when you have people with really strong opinions on trivial things and not open ended sessions. I'm not looking to make money just talk to smart people about things I love doing. So much better than going to a cubicle and having a junior programmer opening up a ticket because their code won't compile.
Any help or is open source just maye not my thing?
It seems like open source programmers are smart people who get stuff done. I've dealt with large, large companies and explain sometimes oh yes "big giant company X does it this way" it works out well but it requires some structure.
Recently retired I'm a bit cast down seeing two great projects and maybe getting into executive, management talk when describing things and I think they just want concrete answers. I really love being in a smart community but I won't commit code without testing or sticking to some basic standards, If they can get something done but it won't install correctly the theme seems to be like "oh well figure out how to uninstall it."
I also explain how large SV companies FAANG or whatever do things at a high level and how effective it s to achieve their goals. From an executive level to an engineering level, They simply dismiss the argument based on it is how Google does it and working with large multi-nationals they do stupid politics and smart engineering.
Like they seem to want to make things hard or I do not know what I'm talking about. They don't think of the end user and how people don't like digging through source code. I'm really depressed, I looked at it like woodworking, I can program but it is hard for me to program when you have people with really strong opinions on trivial things and not open ended sessions. I'm not looking to make money just talk to smart people about things I love doing. So much better than going to a cubicle and having a junior programmer opening up a ticket because their code won't compile.
Any help or is open source just maye not my thing?
I'm not looking to make money but they're really focused on minutia and I'm more of a big thinker. Suggestions on integrating with the communities?
Start with the minutia.
In any given community you're going to have to hang around a bit and be a productive member before people will take you seriously. They have a lot invested in the project and they will not react well to a stranger just coming in and wanting to rearrange things.
You should of course participate in any community message boards, and help answer questions from users on Stack Overflow, etc.
Once people see you as a member of the community they will be more willing to listen to your big thoughts.
posted by Tell Me No Lies at 6:12 PM on June 16 [15 favorites]
Start with the minutia.
In any given community you're going to have to hang around a bit and be a productive member before people will take you seriously. They have a lot invested in the project and they will not react well to a stranger just coming in and wanting to rearrange things.
You should of course participate in any community message boards, and help answer questions from users on Stack Overflow, etc.
Once people see you as a member of the community they will be more willing to listen to your big thoughts.
posted by Tell Me No Lies at 6:12 PM on June 16 [15 favorites]
Often people join professional communities for what you call the minutiae, because they are interested in craft or because that’s their specialty or that’s the kind of problem they’re trying to solve.
If you want to talk about big audacious ideas, this may not be the audience for you. But like Tell Me said above, if you want this audience you have to give them what they’re looking for.
posted by chesty_a_arthur at 7:34 PM on June 16
If you want to talk about big audacious ideas, this may not be the audience for you. But like Tell Me said above, if you want this audience you have to give them what they’re looking for.
posted by chesty_a_arthur at 7:34 PM on June 16
Also, btw, this is a great audience! They want to solve problems! They want your advice! Big ideas are so, so common, but turning them into something a human can do — that’s gold.
posted by chesty_a_arthur at 7:35 PM on June 16
posted by chesty_a_arthur at 7:35 PM on June 16
A lot of people are working on open source projects because they can't or won't do things the corporate way. It sounds like you've found projects that meet this description and you will probably keep annoying each other.
The good news is that there are definitely open source projects that don't run that way too. There are plenty of open source projects out there where most of the commits are by googlers, for instance. They are working on corporate timelines to meet corporate goals and if you prove helpful they'll happily accept your help.
posted by potrzebie at 7:47 PM on June 16 [1 favorite]
The good news is that there are definitely open source projects that don't run that way too. There are plenty of open source projects out there where most of the commits are by googlers, for instance. They are working on corporate timelines to meet corporate goals and if you prove helpful they'll happily accept your help.
posted by potrzebie at 7:47 PM on June 16 [1 favorite]
Open source is all about letting yourself get nerd-sniped. Find something you're curious about, a problem you want to solve, even a tiny one, and dive into codebases trying to figure it out. Do the dirty, unglorious work of actually programming things, debugging minor issues, and so on. This also gains you respect among the people who work on those projects.
Fundamentally this isn't very different from programming at a job -- just the same, you have to work within the bounds of how the organization already works and the preferences of the people already there. At a day job you can't unilaterally decide to make a dozen other programmers work a different way (even if your way really is better) -- and you can't do that in open source either.
It feels like you might be going into this with the assumption that your way of doing things is right (because you have a Lot Of Experience) and that you know better than the open source developers. But you are not, despite what you may think, their senior. From their perspective, you are the novice and they are the ones who have been working on these projects for years.
posted by etealuear_crushue at 8:48 PM on June 16 [4 favorites]
Fundamentally this isn't very different from programming at a job -- just the same, you have to work within the bounds of how the organization already works and the preferences of the people already there. At a day job you can't unilaterally decide to make a dozen other programmers work a different way (even if your way really is better) -- and you can't do that in open source either.
It feels like you might be going into this with the assumption that your way of doing things is right (because you have a Lot Of Experience) and that you know better than the open source developers. But you are not, despite what you may think, their senior. From their perspective, you are the novice and they are the ones who have been working on these projects for years.
posted by etealuear_crushue at 8:48 PM on June 16 [4 favorites]
I work on a very niche open source project. I focus on the minutiae because that's what matters when I'm performing with it. What's it doing when I have a microphone in the other hand and a floor full of dancers waiting on me.
We had a guy come in with what turned out to be some great suggestions and bug reports, but his first approach was to lead with things that weren't about what's happening real time. And the two or three of us who program on it were "yeah, it does that, but I can work around that when in preparing my set, what matters is when I'm on."
Eventually we figured out where he was coming from, and got him on board, and he's been helpful in a non-coding role, but a lot of "big picture" thinking can feel like distraction if it isn't solving the things I need to use the software tonight. I'm scratching my own itches first, and I'm on stage more often than I'm hacking on the code.
And, yeah, it feels arrogant to say "but are you using the software?", and we may be able to pick up more users if we polish the edges, but this is a hobby I do to scratch my itches. And I'm the user I care most about.
posted by straw at 9:39 PM on June 16 [1 favorite]
We had a guy come in with what turned out to be some great suggestions and bug reports, but his first approach was to lead with things that weren't about what's happening real time. And the two or three of us who program on it were "yeah, it does that, but I can work around that when in preparing my set, what matters is when I'm on."
Eventually we figured out where he was coming from, and got him on board, and he's been helpful in a non-coding role, but a lot of "big picture" thinking can feel like distraction if it isn't solving the things I need to use the software tonight. I'm scratching my own itches first, and I'm on stage more often than I'm hacking on the code.
And, yeah, it feels arrogant to say "but are you using the software?", and we may be able to pick up more users if we polish the edges, but this is a hobby I do to scratch my itches. And I'm the user I care most about.
posted by straw at 9:39 PM on June 16 [1 favorite]
They don't think of the end user and how people don't like digging through source code.
Which end users and what product, though?
I think there are projects that care more about user experience, and about thorough testing, than what you describe. Incidentally that doesn't mean a corporate style, that just means an emphasis on certain types of quality and a goal of appealing to a broad, less-techie userbase. This does not seem like a project that's aiming for a broad base. (FWIW I use mostly open source software and it's very rare that I've needed to look at the code - never with big, major projects.)
So you can choose a different project (and build up cred slowly, as described above). Or maybe you can take your current project and see if you can do something like GUI work that wouldn't step on people's toes. Or even just adding helpful error messages or other UI functionality - an additive approach rather than saying "let's completely rethink/rewrite what we're doing here" or "your patch is not good enough". A lot of people see that kind of stuff as tedious, or it doesn't solve their specific problem so they'd rather not devote their time to it, but maybe you can pick up those threads and do the bits no one else has the time or interest for. And maybe you can find an additive approach for testing too - you can't force people to adopt a different submission process, but maybe you can make it very easy for them.
Do you enjoy collaborating with people in the first place? There are also a lot of smaller projects that have been abandoned or are a one-person show and the person could use some help. Or you could start your own project wrapping around or forking some user-unfriendly code.
posted by trig at 12:33 AM on June 17 [1 favorite]
Which end users and what product, though?
I think there are projects that care more about user experience, and about thorough testing, than what you describe. Incidentally that doesn't mean a corporate style, that just means an emphasis on certain types of quality and a goal of appealing to a broad, less-techie userbase. This does not seem like a project that's aiming for a broad base. (FWIW I use mostly open source software and it's very rare that I've needed to look at the code - never with big, major projects.)
So you can choose a different project (and build up cred slowly, as described above). Or maybe you can take your current project and see if you can do something like GUI work that wouldn't step on people's toes. Or even just adding helpful error messages or other UI functionality - an additive approach rather than saying "let's completely rethink/rewrite what we're doing here" or "your patch is not good enough". A lot of people see that kind of stuff as tedious, or it doesn't solve their specific problem so they'd rather not devote their time to it, but maybe you can pick up those threads and do the bits no one else has the time or interest for. And maybe you can find an additive approach for testing too - you can't force people to adopt a different submission process, but maybe you can make it very easy for them.
Do you enjoy collaborating with people in the first place? There are also a lot of smaller projects that have been abandoned or are a one-person show and the person could use some help. Or you could start your own project wrapping around or forking some user-unfriendly code.
posted by trig at 12:33 AM on June 17 [1 favorite]
You need to earn cred as a contributor to the project before they'll be interested in your leadership. (There are alternative pathways but they require that you have a significant portfolio of past open source work and you are not there yet.)
First, do things that a contributor can do with zero credibility, like commenting on nonreproducible bugs to say you have tested them and the report can be safely closed.
Once you have earned enough cred that it makes sense for maintainers to give you a few privileges, do things that require no particular consensus, such as mentoring other new contributors and improving digital infrastructure (e.g. continuous integration).
Once you have done those things enough that other maintainers have formed personal trust in you and are open to making you a co-maintainer, now you can start building consensus for policy change and major infrastructural or strategic change.
If this sounds unappealing and you just want to talk to programmers about programming, focus on finding avenues for that, such as Recurse Center or Lobste.rs.
posted by brainwane at 12:38 AM on June 17 [1 favorite]
First, do things that a contributor can do with zero credibility, like commenting on nonreproducible bugs to say you have tested them and the report can be safely closed.
Once you have earned enough cred that it makes sense for maintainers to give you a few privileges, do things that require no particular consensus, such as mentoring other new contributors and improving digital infrastructure (e.g. continuous integration).
Once you have done those things enough that other maintainers have formed personal trust in you and are open to making you a co-maintainer, now you can start building consensus for policy change and major infrastructural or strategic change.
If this sounds unappealing and you just want to talk to programmers about programming, focus on finding avenues for that, such as Recurse Center or Lobste.rs.
posted by brainwane at 12:38 AM on June 17 [1 favorite]
Which end users and what product, though?
corporations are/have an institutional time scale. that is what makes corps (in opposition to "Citizens United" [Harvard Law Review]) not people. people are alive!
Suggestions on integrating with the communities?
people are more 'open-source' than corporate. corporations may point towards a sociality, that is otherwise experienced by humans. most unfortunately, the way corporations do sociality (capitalism) can be (more often than not?) harmful. what is hopeful about open source is the ideals of freedom this form of communication embodies: bring knowledge you have to the table, corporate or whatever, and share
posted by HearHere at 2:50 AM on June 17
corporations are/have an institutional time scale. that is what makes corps (in opposition to "Citizens United" [Harvard Law Review]) not people. people are alive!
Suggestions on integrating with the communities?
people are more 'open-source' than corporate. corporations may point towards a sociality, that is otherwise experienced by humans. most unfortunately, the way corporations do sociality (capitalism) can be (more often than not?) harmful. what is hopeful about open source is the ideals of freedom this form of communication embodies: bring knowledge you have to the table, corporate or whatever, and share
posted by HearHere at 2:50 AM on June 17
I also explain how large SV companies FAANG or whatever do things at a high level and how effective it s to achieve their goals. From an executive level to an engineering level, They simply dismiss the argument based on it is how Google does it and working with large multi-nationals they do stupid politics and smart engineering.
I've been involved with a relatively small (but well known) OSS project as a core developer for some time. My biggest piece of advice is to listen to the currently active developers. My second biggest piece of advice is to start with small, achievable, non-high-level contributions. OSS projects are just not a scenario where it is viable to swoop in with big picture thoughts about how the whole project development process should drastically change to do [whatever]. You have to both build up cred and genuinely understand whether [whatever] is a viable solution. Also, if you do both of these things in concert you will learn if a project in its current form is not for you; perhaps its approach to testing (which you are not going to be able to change without already being embedded in the project) is just not a good fit.
On FAANG tech specifically: many things that these companies do, really do not scale down. I think it'd be worth your time to think about and understand this carefully, and consider whether your suggestions can actually be practically applied at OSS scale (especially in terms of volunteer time, but also to some degree cost -- which in an OSS project comes out of either carefully hoarded donation funds, or people's pockets). In many cases, I suspect the answer is no. But if you disagree, the solution in an OSS scenario is not just to say "google does it like this", it's to put together a prototype yourself and demonstrate that it is an improvement.
Also, I'm sorry to be critical, but if the writing in this post is representative, they are probably having a hard time fully understanding what you are trying to convey. Most OSS communication does happen in written form, and for a new contributor things like commit messages, PR descriptions, etc., are going to form an important part of how you are perceived. Consider working on this.
posted by advil at 6:49 AM on June 17 [12 favorites]
I've been involved with a relatively small (but well known) OSS project as a core developer for some time. My biggest piece of advice is to listen to the currently active developers. My second biggest piece of advice is to start with small, achievable, non-high-level contributions. OSS projects are just not a scenario where it is viable to swoop in with big picture thoughts about how the whole project development process should drastically change to do [whatever]. You have to both build up cred and genuinely understand whether [whatever] is a viable solution. Also, if you do both of these things in concert you will learn if a project in its current form is not for you; perhaps its approach to testing (which you are not going to be able to change without already being embedded in the project) is just not a good fit.
On FAANG tech specifically: many things that these companies do, really do not scale down. I think it'd be worth your time to think about and understand this carefully, and consider whether your suggestions can actually be practically applied at OSS scale (especially in terms of volunteer time, but also to some degree cost -- which in an OSS project comes out of either carefully hoarded donation funds, or people's pockets). In many cases, I suspect the answer is no. But if you disagree, the solution in an OSS scenario is not just to say "google does it like this", it's to put together a prototype yourself and demonstrate that it is an improvement.
Also, I'm sorry to be critical, but if the writing in this post is representative, they are probably having a hard time fully understanding what you are trying to convey. Most OSS communication does happen in written form, and for a new contributor things like commit messages, PR descriptions, etc., are going to form an important part of how you are perceived. Consider working on this.
posted by advil at 6:49 AM on June 17 [12 favorites]
So now I just didn't want my name tied to the front page but I will say it was based off cloud tech meant for self-driving cars. The kernel was built in layers as a container, it used cloud technologies (independent self contained highly secure apps) without the scalability and complexity of K8s. It was meant for sedurity and composability. The problem is that a lot of laid off (I assume) devvelopers were bringiing this to open source and a lot of the documentation was wrong and very complex. Not from a scability point of view but I believe from a security point of view. To extend the base operating system you had multiple ways of doing it, one of which was defining the GPT partition. Upgrades would seem to override previous upgrades but user data was taken first, squashed and now seen as the base OS. I'd call this drift. I would assume iimmutable data would be in a volume or dot files as even the home directory would change structure or at least how it is used between upgrades. For casual users or those not developing applications this was not an issue but if you were developing apps a lot of software did not come in packaged sandbox apps (Flatpak, Brew) and the way the immutability was written was to write raw image packages as I first described. Works great if you're a car, but I found most people would have home labs they'd blow away the OS and just simply reinstall from scratch, or create an img file to apply over it. There were some idealogical differences beyond that as to adding apps but having no way to uninstall them, to avoid the complexity of the systemd.sysext system.
Since the systems were meant to be stateless as designed the hacks kind of didn't work. There was no roadmap and people just kind of did things and I was trying to help but I got into a rabbit hole of "why is this here and the rest of the things related to it here" which might have been a simple mistake or design choicie. Since there was no project roadmap and software designed not really meant to be immutable I suggested a Bazel sort of alternative and suggestions to bring in dependencies we needed and refactor them to be immutable. Otherwise it'd end up as hacks, that did dnot go over well. Furthermore I noticed that other projects virtualized everything and loaded the kernel and drivers inside bios/UEFI (or rewrote their own). Some of this was simply because you're adding a bunch of the same containers that really are stateless but the concept in general seemed to make sense. If the "host OS/daily driver" is upgraded simply redownload it, load customization from a volume and maintain your other containers/VMs separately on your laptop (say ollama).
I was throwing these ideas out and I had not taken OS dev in years let alone learned containers/microVMs/toolboxes came thse separate but sort of the same thing. So I went through source code and developed the ideas to see if it would work. Could I load a network stack (DNS/DHCP) first, then the graphical OS, then the VMs in order and would it work? It seemed nVIdia passhtrough was the biggest hurdle. Loading all these within the graphical OS required paravirtualization and I did not know how the GPU passhtrough would impact the product.
Given these products were new and some were just coming out I was hoping for some simple answeres as "googling" didn't work. Instead the focus somehow came to just rebuilding the OS and VM it contained.
I wasn't tryiing to "corporate" this but had some basic questions that I think no one wanted to answer or were stupiid. I took OS development 20 years ago one semester. I was reading up on this but even latest test guides didn't take into account AWS would rewrite the UEFI using Nitro and create components that were all virtualized.
Looking back I am passionate about technology but some of these things are new and change quickly. Instead of asking questions or suggesting things I probably communicated in my big manager voice of do this, when really I was looking for someone to point me to some resources. I have not coded professionally in years (though on the side) began to hate upper management's focus on partnership and numbers and dealing with non-coders, found a project that not only I found interesteing would help keep me ontop of things. It was made so that you could develop in whatever workflow you wanted, put together niciely in that respect, and didn't require standards.
I should have forked a simpler version of a Linux variant and played around with it and kept my mouth shut. i read up on EDK2, etc. Most my friends are corporatized and don't need a flexible development environment. Checkin a container, hand it off to another team, they'll make sure you're not running a db on each container to the same volume, get it K8S ready, etc. So the tools this provided confused them. I guess I was looking to getting into tech again and found they were not looking for questioning why things were done (serious questions, not questioning if it was wrong) and it was taken obviously in negative way.
The good news is I still got it (I got EDK2 running and booting from a VM image!), understand that virtualization is probably the way things are going and finally understood WASM outside the browser. As someone who would write an app when I did so it was writing an app into a container, "works on my machine" with consideration to deployment environment but I was actively discouraged from cross compiling or doing anything that wasn't set in stone. Even as it became "my department" politics played a big role in keeping things conservative.
I really like development but also see the long-term roadmap of sure lets hack here or there but do we want to put effort if we know we're going to this new tech when the upstream release is in a month or two? I communicated that as if I was talking to middle management. Not my intent just how I learned to speak and this team didn't care, they just wanted to commit, so I'll take it as my fault and probably why I ended up disgruntled upper management and they're happy not thinking about long term complications. Or at least wanting to talk about them. I probably was also looking for a social network.
Just a time in my career where I can't tell if I'm too old or out of touch to go back to development which I love but my resume has "big SI" all over it who moves numbers or what. I hate stand-ups and theater that goes with it but get that's what giant companies want, so it was a relief to not have to do that.
At the same time my friends went another path of steady corporate jobs, developed or architected (whatever that means) and so after they settled down they kind of lost the passion for not following what's a new tech bro product but actual changes in the industry. Definitely not looking to make money off open source or anything like that just wanted to again, treat it like wood working and if I have to go back to making silly decisions at a management level I at least have something I enjoy.
posted by geoff. at 12:21 PM on June 17
Since the systems were meant to be stateless as designed the hacks kind of didn't work. There was no roadmap and people just kind of did things and I was trying to help but I got into a rabbit hole of "why is this here and the rest of the things related to it here" which might have been a simple mistake or design choicie. Since there was no project roadmap and software designed not really meant to be immutable I suggested a Bazel sort of alternative and suggestions to bring in dependencies we needed and refactor them to be immutable. Otherwise it'd end up as hacks, that did dnot go over well. Furthermore I noticed that other projects virtualized everything and loaded the kernel and drivers inside bios/UEFI (or rewrote their own). Some of this was simply because you're adding a bunch of the same containers that really are stateless but the concept in general seemed to make sense. If the "host OS/daily driver" is upgraded simply redownload it, load customization from a volume and maintain your other containers/VMs separately on your laptop (say ollama).
I was throwing these ideas out and I had not taken OS dev in years let alone learned containers/microVMs/toolboxes came thse separate but sort of the same thing. So I went through source code and developed the ideas to see if it would work. Could I load a network stack (DNS/DHCP) first, then the graphical OS, then the VMs in order and would it work? It seemed nVIdia passhtrough was the biggest hurdle. Loading all these within the graphical OS required paravirtualization and I did not know how the GPU passhtrough would impact the product.
Given these products were new and some were just coming out I was hoping for some simple answeres as "googling" didn't work. Instead the focus somehow came to just rebuilding the OS and VM it contained.
I wasn't tryiing to "corporate" this but had some basic questions that I think no one wanted to answer or were stupiid. I took OS development 20 years ago one semester. I was reading up on this but even latest test guides didn't take into account AWS would rewrite the UEFI using Nitro and create components that were all virtualized.
Looking back I am passionate about technology but some of these things are new and change quickly. Instead of asking questions or suggesting things I probably communicated in my big manager voice of do this, when really I was looking for someone to point me to some resources. I have not coded professionally in years (though on the side) began to hate upper management's focus on partnership and numbers and dealing with non-coders, found a project that not only I found interesteing would help keep me ontop of things. It was made so that you could develop in whatever workflow you wanted, put together niciely in that respect, and didn't require standards.
I should have forked a simpler version of a Linux variant and played around with it and kept my mouth shut. i read up on EDK2, etc. Most my friends are corporatized and don't need a flexible development environment. Checkin a container, hand it off to another team, they'll make sure you're not running a db on each container to the same volume, get it K8S ready, etc. So the tools this provided confused them. I guess I was looking to getting into tech again and found they were not looking for questioning why things were done (serious questions, not questioning if it was wrong) and it was taken obviously in negative way.
The good news is I still got it (I got EDK2 running and booting from a VM image!), understand that virtualization is probably the way things are going and finally understood WASM outside the browser. As someone who would write an app when I did so it was writing an app into a container, "works on my machine" with consideration to deployment environment but I was actively discouraged from cross compiling or doing anything that wasn't set in stone. Even as it became "my department" politics played a big role in keeping things conservative.
I really like development but also see the long-term roadmap of sure lets hack here or there but do we want to put effort if we know we're going to this new tech when the upstream release is in a month or two? I communicated that as if I was talking to middle management. Not my intent just how I learned to speak and this team didn't care, they just wanted to commit, so I'll take it as my fault and probably why I ended up disgruntled upper management and they're happy not thinking about long term complications. Or at least wanting to talk about them. I probably was also looking for a social network.
Just a time in my career where I can't tell if I'm too old or out of touch to go back to development which I love but my resume has "big SI" all over it who moves numbers or what. I hate stand-ups and theater that goes with it but get that's what giant companies want, so it was a relief to not have to do that.
At the same time my friends went another path of steady corporate jobs, developed or architected (whatever that means) and so after they settled down they kind of lost the passion for not following what's a new tech bro product but actual changes in the industry. Definitely not looking to make money off open source or anything like that just wanted to again, treat it like wood working and if I have to go back to making silly decisions at a management level I at least have something I enjoy.
posted by geoff. at 12:21 PM on June 17
(Sorry for the wall of text midlife crisis I think I approached it wrong and I think some legit questions were misinterpreted or it was well known amongst the crowd how cloud architecture works which on top of a layered container architecture doesn’t get a lot of news).
posted by geoff. at 2:10 PM on June 17
posted by geoff. at 2:10 PM on June 17
My one suggestion would be to take the time to review and edit what you write, write shorter sentences, and perhaps rearrange or even delete stuff in the process. Your FPP (above the fold) and then this latest comment had huge run-on sentences that I gave up on parsing. Perhaps your OSS colleagues are similarly annoyed. Invest the time to write more clearly. It's not a race.
posted by intermod at 3:39 PM on June 17 [8 favorites]
posted by intermod at 3:39 PM on June 17 [8 favorites]
Hah! I'm glad you outed yourself geoff. -- I read this Ask and immediately knew who had written it.
You've gotten some good advice here, and I want to highlight:
1) I know it may be hard to come in with zero credibility and work your way up starting with what feels like low-status grunt work, but you really should listen to brainwane. She's an expert in this space, and has given you a solid playbook on how to engage with an open source project.
2) I can't favorite intermod's advice hard enough. Your writing style on Ask is notable for its lack of clarity, and if this is consistent with how you attempt to communicate professionally, it's unsurprising that you are having problems. You might want to think about hiring an editor who specializes in technical communication to work on improving your writing skills.
posted by Metasyntactic at 8:08 PM on June 17 [9 favorites]
You've gotten some good advice here, and I want to highlight:
1) I know it may be hard to come in with zero credibility and work your way up starting with what feels like low-status grunt work, but you really should listen to brainwane. She's an expert in this space, and has given you a solid playbook on how to engage with an open source project.
2) I can't favorite intermod's advice hard enough. Your writing style on Ask is notable for its lack of clarity, and if this is consistent with how you attempt to communicate professionally, it's unsurprising that you are having problems. You might want to think about hiring an editor who specializes in technical communication to work on improving your writing skills.
posted by Metasyntactic at 8:08 PM on June 17 [9 favorites]
"and found they were not looking for questioning why things were done (serious questions, not questioning if it was wrong) and it was taken obviously in negative way."
Can you quote or link to specific questions you asked that the project maintainers responded to in a way other than you'd hoped? Reading those specific words will help us advise.
In case you can't do that:
Based on what you've written here, I infer that, most of the time, you did not successfully get across that you were genuinely and humbly and nonjudgmentally asking how the project's architecture and infrastructure had been set up, and why they'd made the choices they had made.
posted by brainwane at 9:35 PM on June 19 [1 favorite]
Can you quote or link to specific questions you asked that the project maintainers responded to in a way other than you'd hoped? Reading those specific words will help us advise.
In case you can't do that:
Based on what you've written here, I infer that, most of the time, you did not successfully get across that you were genuinely and humbly and nonjudgmentally asking how the project's architecture and infrastructure had been set up, and why they'd made the choices they had made.
posted by brainwane at 9:35 PM on June 19 [1 favorite]
You are not logged in, either login or create an account to post comments
Some open source communities are going to be more hobbyist-driven, others more corporate-driven, with a huge range in between. I think it is reasonable to guess that for most, the developers are very likely to be users as well, which is a pretty different situation from the commercial world.
posted by jimw at 5:56 PM on June 16