In my opinion, the most difficult problem in open source software development (OSSD) is the incentive structure. How do we motivate people to work for free? More importantly: how do we motivate highly skilled developers who could otherwise spend their time making buckets of money? The greater good isn’t always good enough for good developers.

Kevin Fleming works at Bloomberg. I am still confused about his role. He’s definitely not the cto (he corrected someone on this). From his linkedin: “Member of the CTO Office at Bloomberg LP”. When asked about his day to day, he responded that he shows up to work with one task in mind and leaves having done several. He has a generalist skillset, leaning more on coordinating engineers than implementing the tech itself.

I found the speaker interesting, especially Vicky’s insights in data engineering and Deena’s opinions on some software that data engineers (python) and archivists (OpenRefine) use. I had Deena my freshman year three years ago when I took intro to programming, so it was nice to hear her give a talk.Vicky had some insightful ideas on what it means to be a data engineer, where a statistician begins, and where a data engineer ends.

Things that I learned:

• Make changes on a branch, and then merge to master. Don’t commit directly.
• It’s hard to commicate accross pages with JavaScript.
• Lots of websites don’t use img tags to load images.
• Don’t be afraid to start over.
• There can be more than one way to solve a problem, but not all solutions are equal.
• Hackiness > Robustness when you don’t care about code longevity.
• You can commit for pretty much any change.
• CSS allows you to manipulate lots of image properties. We used these to discount deepfry our images.
• Blurriness approximates pixellation.
• It can be hard to find high quality images.
• Have someone on your team with photoshop skillz.
• Use Ubuntu workspaces.
• Blogging with git and github is surprisingly useful.
• I still don’t quite understand the point of Jekyll. (simplify static web development by transcompiling into html and css, nice)
• I’m trying not to repeat things that I wrote in my last blog post but I need to hit at least 300 words and it’s getting hard.
• Good looking icons make you look professional.
• The joke doesn’t wear off.

Our group creatd Mockbob. It replaces normal text on a page with spONgeBoB mOCkiNG tExT, deepfries images, and changes the font. All p, a, and h tags that contain the chosen text are mocked. If the user doesn’t specify text, it defaults to ‘NYU’ and ‘New York University’. Working as a group was easy: we created a repo, uploaded some code, then worked until it was finished. The work was distributed well, I mostly did the the javascript, Nishant worked on the graphics/css/html, and Amad worked on the github. There was little code overlap.

I learned how successful a group can be with effective distrubution of labor. Each person’s contribution was high quality work, so there was no need to spend time working on another’s contribution. We experienced very little merge pain for this reason. All branches we worked on generally used different parts of the project, so there was only one instance when two branches changed one piece of code.

For me, the words open source appear most often when looking for a solution. Some recent examples include: a new e-reader, converting mobi files to epub, and building a new keyboard. Whenever there is a software problem, there is often a for-profit proprietary solution and an not-for-profit open source solution. There can be one FOSS and one proprietary, many FOSS and many proprietary, and everything in between. For example, photo editing has (effectively) only GIMP vs Photoshop. Linux vs Windows/MacOS. Textmate/Sublimetext vs VIM/VScode/Atom/etc.