Working in open source, can be beautiful and destructive. It’s an interesting ecosystem of different individuals all around the world, contributing to various different projects they believe in.
These last couple of weeks felt like I had just entered into an old 1960 western starring Clint Eastwood. I am including Eastwood because of the amount of squinting I had to do for the long periods of time I was looking at a monitor.
Open Source Thoughts
There is a lot to take in – I worked on two pull requests, one for an internal project that was moving the speed of light, and the other Visual Studio Code, something that I use and appreciate very much, and feel is a strong IDE. I don’t believe in making a blog solely on complaining, so when I talk about my responses below. These are things I felt were very beneficial for my growth.
Things I Liked
- Any project
- Friendly open source community
- Reading tons of different styles of code
- Witnessing how large a project can be
- Discovering new tools and libraries relatively simple
- Learning git to a higher degree.
- Different coding backgrounds coming from all over the place
Things I Disliked
- Waiting for previous issues that I could do myself to be done before I could proceed
- Conflicts, and people cheating the system.
- You can just as easily join and leave a community
- Hard to understand the overall work flow of the project
- Hard to communicate in real-time on projects
- Individuals who aren’t owning the repository making executive decisions (in terms of coding style.)
Keep in mind these were spent over a short period of time, and just the problems I saw for the probably 20 hours I put into working on both my internal and external request.
I don’t feel like either the pros or cons will go away. The exception being when I worked on visual studio code. Someone from microsoft has to approve or disapprove your pull request and issue. However, many of the projects don’t have that level of service. It’s actually odd that microsoft does, huge corporation that has billions of dollars utilizing on an open source community to help push them forward is a really weird conundrum, and I’m assuming it’s probably to not stifle the level of creativity that can be input into their product that they look at as the best approach to stay ahead of the curve.
What were the pull requests?
Visual Studio Code
The first one, Visual Studio Code, is adding the Cntl-shift-C feature and Cntl-shift-V feature to Windows terminals. Now, who uses it? Well, apparently it’s becoming standardized in many terminals, and I believe already the standard way of practicing in Linux. When an individual has to switch back and forth through systems, thats where the issue lies. Muscle memory fails them.
Now, I initially got stuck because the issue read cntl-shift + *. You can see the issue here.
So I scoured the internet, far and while for this mysterious combination of cntl-shift and *. Yes, I couldn’t see a tree from the forest…or a forest from the tree. I’m not sure the saying. The * representing an infinity possibilities. It wasn’t a specific function attached to ‘*’.
Now, eventually I tried somethings, and my code was actually incorrect, however due to a custom setting I had on my computer, it did not work in the submitted copy, so I had to make some changes.
I found working with visual studio code, very simple, easy, super helpful staff, and I hope to continue to work with a project that has a very nice working structure. Great use of maintainers, little hassle for the merge, and very clear cut coding guidelines.
I enjoyed this despite some of my wasted time setting everything up quite a bit.
This project is far more interesting, created far more issues, and made me re-think about opening or starting a project on open source. And to clarify, open source can be a really good thing.
Well, because this was a brand new project, I felt there was a lot of growing pains that the open source community isn’t as equipped for. A lot of problems are stumbled through or on during the start of a new project. Now, these aren’t problems that can’t be fixed, especially with the amount of people working on this however, depending on where you are at, and when you want to contribute thats where this will let you down. For my particular times issues exploded, like a volcanoe.
Everyone trying to jump on the issues that are easiest, ones with large amounts of code easily added or ones they felt comfortable doing. The issue? Well, a good example was the “express server.” This was something that I believe was done, almost a week later after the issue, and done extremely well. However, the parts that I wanted to interact with did not need that same level of quality. I needed a rough express server, just so we could move forward faster with SAML introduction. This was an issue that directly affected me, and depending on how long or the other individuals time, would dictate what I could have done. However to deploy my own express server, would have taken me less time, and easier to test. Frustrating experience as I don’t necessarily think in open source that doing more is always better. It’s staying within your issue and accomplishing your issue I feel is more important. The faster that issue is dealt with, creating your next issue should be relatively simple, this allows for a much simpler flow.
There’s also the case that I saw others run in, which is styles of code. Well, early contributors got to kind of “dictate” this, or individuals who chose the large amounts of code. This is an odd scenario to have happen, and one that only is kind of near the start of the code when so much code is flying around. I almost feel like its better to have some ground work set-up before an open source project is opened to the public for this reason, as I think there are some questions that need to be answered prior too the start of a project to lessen the growing pains to a ton of devs that are relatively new. I do envy the next class that gets to work on this project. As a lot of these things will be dealt with by the time they are up to perform.
They’ll also not have to hopefully deal with the crazed package-lock.json file, and its ever changing ways because hopefully by the end all the packages we need will be installed. Although thats an issue, I don’t think it’s one that will pop-up on the regular due to the vast amount already added.
To say these weren’t great character building scenarios would be dishonest, they definitely helped me think more critically on how I would like to manage my own future projects. And for that I am greatful, while someone else may jump into a similar situation, perhaps if we didn’t have the great David Humpries at the helm who was more knowledgeable, I truly do feel the ship could just as easily sunk with someone with less experience.
My last post talked about my limits, and I do feel like I was able to push through these issues, however much like Dragon Ball Super ended, the truth is, you push through these limits through the help of friends.
For a scene that accurately reflects my feelings which are that Jiren (The bald headed super muscle-y dude.) is the problems we face, and goku is the embodiment of pushing forward and the impact friends can have on us.