Sustain Our Software

"The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is available on Amazon. Get your copy here today only for $2.99!

Serkan is a freelance software developer who has been developing web applications since 2001. Lately he has been working with Angular and ASP.NET. He shares that he has been studying sustainability of open source issues since 2014 and also shares the abridged version of how he came to be involved with the open source community.  Richard then asks Serkan to share more details on how he as a developer became interested in open source. He shares how as a developer working on proprietary software he often found himself working on similar solutions in different companies and he realized that he was building the same software solutions over and over. From this he concluded that open sourcing these types of projects would reduce the need to keep creating these projects by sharing the solutions between those that need them. Serkan points out the problem with the way open source works now is that it’s difficult to make money in it and as such he started looking for ways to fix this problem. He has the desire to find ways to move money from proprietary solutions into open source. Serkan asserts that the only real difference between proprietary software and open source software is licensing and furthermore that any software could be open source.  The next topic discussed by the panelists is the changes they’ve seen in the last five years for funding open source. Serkan highlights that he believes that many companies are coming to understand that the future is positive with open source and those companies are beginning to move that way. Richard responds by sharing the importance of building structures around funding developers who decide to open source their software.  Serkan moves the conversation to a deeper analysis of proprietary rights. The panelists discuss a survey of developers taken by Tidelift that shows that many professionals prefer open source software over proprietary software. The panelists then have a deeper discussion on what the reasons and drawbacks are for proprietary companies to turn open source. They also discuss how to create a tax of sorts that starts funding proprietary solutions turned open source and who would start that process.  The open source experts then discuss how it is difficult to convince individual companies to go open source because their focus is on growing their business and making their own software prosper. Serkan responds to this by saying that open source is an investment that can pay dividends in the long run. They also share ideas on how working with governments and individuals could help to facilitate the transition to greater worldwide involvement in open source and propel the software industry forward to supporting open source.  Serkan closes by reiterating some thoughts he shared earlier that governments are already involved in a wide range of programs that benefit all of its citizens. He shares how the sustaining of open source could be another program that is added to a government’s agenda and the opportunities that a government has to be of help in contrast to companies and individuals.  Panelists

• Richard Littauer
• Pia Mancini
• Eric Berry

  Guest

• Serkan Holat

Sponsors

• iPhreaks
• Adventures in Angular
• Adventures in .NET

Links

• Angular
• ASP.NET
• Chad Whitacre Medium

This episode of Sustain our Software features Abigail Cabunoc Mayes. Abigail has a background in bioinformatics and computer science and has an interest in using computers to solve problems in biology. She works for the Mozilla Foundation where she is a practice lead working Open. She has been named in “100 Awesome Women in Open source” and mentioned in Github’s State of the Octoverse 2016. Abigail begins by sharing some of how she got started and what interests her in technology. The discussion then moves to altmetrics and how Abigail helps people publish code and get recognition for their work.  Richard asks Abigail how her work for mozilla fits into the type of work she is known for. Abigail shares that Mozilla is much more than the Firefox browser that it is known for. Abigail shares that “Mozilla’s mission is to ensure that the Internet is a global, public resource” that is “open and accessible to all”. This mission at Mozilla goes back to the browser wars of the early 2000’s when they created Firefox to ensure that a web browser was available to all. Abigail goes into further detail how the Mozilla foundation helps to further the internet and open source as well as what she is currently working on.  The next topic covered by the open source experts is the tooling used by Mozilla to maintain privacy. Abigail notes that some of the issues that prevent a healthy internet are privacy and security, openness, decentralization, web literacy, and digital inclusion. She shares that Mozilla is very conscious of protecting users and how they walk the line between privacy and openness. They also discuss how Abigail grows leaders in the community. She shares how it starts with identifying potential leaders and how she finds them. Currently Abigail is teaching a course on how leaders can run their own versions of Mozilla’s Open Leaders through an online program that meets every two weeks. Abigail goes through the details of how the Open Leaders program works.  Eric then asks Abigail to explain what openness means to her. She shares that openness and movement building really work together. They are means of rallying people together and empowering them to work towards a shared goal. Openness means to both be public and participatory and be active in the community. Richard follows up by agreeing that openness means to be participatory and is a pillar of open source. Abigail adds that as a leader it is very important to be able to delegate tasks and entrust responsibility to other members of the group. She goes on to say that it is vital to open source sustainability for others to be able to contribute to a project.  The panelists then lead into a discussion on why maintainers leave a project and what happens when they do. Eric asks Abigail how to teach someone to delegate to which she explains that it is important to help people see how a broader community with diverse perspectives can help propel a project forward. To get contributors to stick around, it is important to give them ownership over a piece of a project. The panelists conclude this episode with covering how to avoid abstracting too much and talking about what’s coming up next for Abigail. Panelists

• Eric Berry 
• Richard Littauer

  Guest

• Abigail Cabunoc Mayes

Sponsors

• Dev Ed
• Views on Vue
• Adventures in DevOps

Links

• Mozilla Foundation
• Mozilla Open Leaders

The special guest for this episode of Sustain our Software is Kevin Owocki. Kevin is the founder of Gitcoin, a service that links up freelance developers with people who need them and pays these developers in crypto currency. Gitcoin is a blockchain forward brand that is built on open source software and currently uses Ethereum as its crypto currency of choice rather than creating their own. They like Ethereum because of its relevance as the 2nd most popular cryptocurrency at the time of this episode. By incentivizing open source contributions, Gitcoin has become an important contributor to the funding of open source software.  Pia begins the discussion by asking Kevin how the bounty system is governed for Gitcoin and Kevin shares some of their structure, process, and philosophy on the subject as well as Gitcoin’s desire to make it easy for developers to find work on their platform. The panelists then discuss how they think the future of the job market will change with the emergence of blockchain. The discussion starts with stating that bounties are the current popular system but Eric says he would look to see a blockchain based paycheck network among other ideas. Pia questions how Eric’s ideas can scale to the larger open source ecosystems and how to have a conversation with a company to open a wallet with Ethereum. Eric responds with some of his ideas on how to make this work as well as some roadblocks they might face. One of the biggest challenges is that the technologies involved are newly emerging and this brings along some skepticism with it.  Richard then asks what Kevin’s long term view is that goes beyond the current system even though things are working really well right now. Kevin shares his aspiration that Gitcoin becomes a network that is owned, built by, and built for coders. This means that they find a way to distribute Gitcoin’s equity to the community and sustain open source through those means. Kevin shares that he does wish to go beyond the bounty system and some of his thoughts on how he hopes to accomplish that.   The conversation then moves to networks and peer communications. Pia raises a concern that some people who don’t have an aptitude for communication often get left behind. She asks Kevin how Gitcoin helps to overcome challenges for those who struggle to get involved. Kevin shares some thoughts on why certain demographics struggle and makes the point that a difference could be made in how those in the field prioritize diversity. Kevin talks about the sustain conference and some of the great opportunities he had when he attended the prior year. He had the opportunity to talk to other professionals and share ideas on web3, blockchain and sustaining open source. The final topic covered by the panelists is who the big contributors are that are making a big difference to sustain open source. Kevin names a few companies that he feels has made a difference and a high level view of what they have done.
  Panelists

• Pia Mancini
• Eric Berry
• Richard Littauer

  Guest

• Kevin Owocki

Sponsors

• Adventures in .NET
• React Round Up
• Adventures in Blockchain

  Links

• Gitcoin
• Ethereum
• Web3
• Sustain OSS Conference

Robert Kaye is the executive director of the MetaBrainz Foundation, the legal umbrella for MusicBrainz. He got started in the late 80’s and early 90’s hacking on some MP3 projects when most of the world hadn’t heard of MP3. The metadata on MP3s was terrible, so he started creating the database known as MusicBrainz. Robert talks about his business model for MusicBrainz. As time has progressed, more and more people have access to a laptop and cheap recording equipment. This constant churn of data gave them the ability to play gatekeeper. Their goal was to take that data and make it cleaner, better, and provide context. In 2003 they started a service called Live Data Feed, which allows anyone to set up a copy of MusicBrainz. Turning on Live Data Feed gets you updates to your copy of MusicBrainz. The idea was to take the recognition they had around Live Data Feed and created monetary value from a service around timely and convenient packs of data. In 2015, MusicBrainz realized that the actual value they had wasn’t in the data, but in the community of people editing the data took. So, they took a radical step and quit caring about code licenses. Now, it is based off memberships with monthly fee. This has worked spectacularly. They have taken to calling their customers ‘supporters’, because if the database is going to stick around then they need their support.  BookBrainz is a similar project to the MusicBrainz database, but applied to books. The project has grown large enough that Robert had to hire a full time engineer to work on it. They deal with disambiguation, deduplication, and conflicts in the  metadata so that organizations like internet archives and Open Library can build other tools on top. For the past 4 years MetaBrainz has also been working on two other projects. AcousticBrainz is machine learning analysis applied to individual songs to determine what music sounds like. It can determine acoustic characteristics such as male or female vocals, presence of certain instruments, and beats per minute. ListenBrainz tracks your listening history, similar to LastFM. In fact, you can import your LastFM history into ListenBrainz and it will do a metadata report on what you’ve listened to. Robert notes that if you choose to learn ListenBrainz your data will be public. These two projects form the perfect basis for building a collaborative filtering algorithm and give you personalized suggestions of what you may also like. They also have a program to work with AcousticBrainz to track what you listen to and the similarities between the songs. They are currently working on compiling the data, but this open source project will enable anyone to come in and create an open source music recommendation engine. When building a recommendation engine, the idea is if there’s a small/medium music label with one computer geek on staff, they can get access to MusicBrainz and download their recommendation engine and start getting their stuff out there, and have it personalized to the listener. Robert’s inspiration for these databases came from seeing a lot more recommendation engines that are entirely biased and want to push their content. He realized that these recommendation engines were designed to feed money back into the system and keep everyone inside the ‘walled garden’ of music. He got funding for these projects through his good relationships with other companies and because they were giving him the money for MusicBrainz, which is enough money, so the extra money is funneled towards other projects. The MetaBrainz Foundation emphasizes quality of life for their employees, and Robert and the panelists discuss how he reconciles this quality of life versus the desire to get all this stuff out the door. Robert believes that if you trust your team and empower them to do what needs done, they will do their job. He only really gets involved if it’s legal concerns, monetary issues, or the rare high priority assignment. His company has few...

Episode Summary In this episode of the Sustain Our Software podcast, Benjamin Nickolls talks with the panelists about the potential for an open source community that is self-sustaining. Benjamin helped create Octobox, a notification system for GitHub, which helps filter messages that one receives through GitHub. Benjamin and his partner created Octobox hoping it would be a model of a sustainable open source project, and after 9 months of working on it full time they have been able to step away from it as it continues to pay for its own hosting and software development. The money that they received from the community was donated back into the community to be able to experiment with paying for development in the open source crowd. There are still times when they need to go back in and maintain it, but for the most part it is a self sustaining software.  Benjamin explains that as they tried to increase the amount of people paying for their services they noticed that there was organic growth that was occurring so they decided to step back and let it continue to grow on its own. Benjamin and his partner are both interested in seeing how Octobox can lead the way in a new way to create open source development and be an example for effective sustainability and maintainability.          Before Octobox, Benjamin and his partner created Libraries.io which helped people search open source software to find what is being used the most by the community. This has stemmed research about the ecosystem of open source software. Open source projects are an extremely diverse thing coming from different builders, maintainers, and funders. Donations, paid services, as well as grants have been the best source for funding for his projects. Diverse funding has created better stability.          They discussed the different ways of funding and its benefits through different platforms. Codesponsor was created to help make funding more acceptable on the open source marketplace although there were many critics. GitHub sponsors has been created to promote individual sponsorships for developers similar to how Patreon works. Benjamin is wary of sponsoring individuals because of possible burnout or the individual could feel over committed to the project and will not work on anything else. The lack of diversity in sponsoring an individual compared to sponsoring groups and teams of people is problematic because of this tendency to get burned out before the project is complete.. He stresses throughout the podcast the importance of diversity in every aspect of developing to maximize sustainability.           Benjamin wants to start seeing a push of funding towards developers who are creating products that aren’t as visible to the community instead of all the funding going towards those who are building off of the less seen projects and have a bigger name in the open source community. If those who are able to receive money through open source projects are able to put it back into the community, there will be a more stable and self-sustaining environment for developers.          The panelists discuss how open source communities have been driven by hobbyists in the past, but the need for change is coming because of the dependency that has been created on these communities. Simply giving those developers what they have received in the past may not be sufficient now that it is a core part of almost every application. Panel

• Richard Littauer
• Eric Berry

Joined by special guest: Benjamin Nickolls Sponsors

• Adventures in Devops
• CacheFly
•  

Links

In this week’s episode of Sustain Our Software the panel interviews Laura Gaetano. Laura is a developer and designer, whose main job was running was running Rails Girls Summer of Code. The panel considers how great Rails Girls is and all that they are doing. The panel also expresses their love for the Rails framework.    Laura explains the difference between Rails Girls and Rails Girls Summer of Code. The panel asks about the challenges that the Rails Girls Summer of code experience. Laura tells the panel how open source and the Ruby community has changed since they started. When they first started Rails Girls Summer of Code there was a lot less support for open source and diversity in programming. Now their main challenges are lack of resources, such as money and people who are invested in Rails Girls Summer of Code for the long term.    Other challenges in the organization stem from the nature of the organization. They are just trying to get everything done, that things like documentation and long term management solutions get forgotten. They want to get all their experience for the last six years documented so that knowledge can help in the future of Rails Girls Summer of Code.    The panel considers what a great feeling it is when people use or contribute to their open source and ask Laura what it’s like to actually help someone become a developer through her open source efforts. Laura explains how amazing it is to see women from past Rails Girls Summer of Code and their success. Laura shares her love of open source and the collaboration that happens in the community. Doing Rails Girls Summer of Code she gets a lot more human contact than in typical open source projects, she explains how that has made a difference in the way that she sees open source.    The panel asks Laura about the state of diversity in open source. Laura explains that there are initiatives out there to support diversity in opensource. She invites everyone to visit opensourcediversity.org. They provide resources to learn about diversity. They even have an open forum where people have a safe space to learn about diversity. She explains that diversity is now a common talking point at conferences to help improve diversity by educating developers about it. The panel discusses making projects more inclusive and explains how Github added s social impact feature that helps make your project more inclusive.    The topic turns to a talk Laura gave in 2017. Her talk explains that open source needs more than code. She explains that she would like to see more crowdsourcing of knowledge and design in open source. Programming is a major part of open source and she is so impressed the how willing programmers are to volunteer their time. However, she would love to see that desire from other people in the technology industry. Open source would be more maintainable if they had people marketing, networking, documenting. Having open source maintainers who focus on these things would help generate more funding and make it more sustainable.    The panel considers why there is such an emphasis on the code contributions, even more so than managing or other roles in open source. Code is a very visible contribution, easy to hold up and say look what they did. Other roles aren’t so easy to hold up, how can someone hold up the hours they spent finding sponsors or perfecting documentation.
  The discussion turns to mental health in open source. Laura talks about her own state of mind and how hard it can be to get herself to do anything when she is feeling burnt out. She explains that she needs to change the way she approaches work.  The panel discusses ways that we can help those experiencing mental health problems in open source. They suggest talking to each other more about their experiences, about what depression, anxiety, and burn out look like and how they affect different people. The panel discusses what processes can be put in place to help...

Episode Summary In this week's episode of Sustain Our software Titus Wormer joins the panel to discuss his experience maintaining Unified.js.  Titus is built Unified and is working fulltime maintain Unified. He has a bachelor's in digital design and did his thesis on fixing natural language in wed design using syntax trees.   The panel takes a moment to talk about abstract syntax trees. Titus explains how abstract syntax trees help computers understand what is going on in human languages, helping programs like Babel and Google Translate.   Titus also does a lot of his work in markdown and the panel asks him why he started working in markdown. Most developers work in markdown and HTML explains Titus, plus markdown has some great tools. In opensource he needs a lot of Read Me’s so Titus built tools in markdown to check on his Read Me’s.    Moving on to the sustaining of Unified the panel asks Titus about the funding he is receiving for Unified. Titus explains a little about the setup of Unified and what goes into maintaining it. Unified has over 400 repositories on Github that need to be maintained, and as Unified gained popularity so did the amount of work needed to maintain the repositories. Titus shares how stressful it was to come home from his everyday paying job to find more and more requests piling up.    Titus decided they needed a change, so last November they started an open collective and looking for sponsors. Titus shares how easy it was asking his users for money and the amount of support they received. According to Titus, about 90% of their funding comes from large company sponsors. The panel discusses his experience in finding these companies and getting them to sponsor Unified.    The panel wonders how much time Titus spends fundraising. Titus explains what it was like when they first started the open collective. They were getting some funding but not enough to pay someone to work full time maintaining Unified, so they didn’t really know what to do with it.    The panel brings up an article about developers working for salaries under the poverty line because of the lack of sustaining funds for opensource projects. They consider specific projects and how much funding they receive annually.   Titus shares his opinion on this article. He believes people support what they see that they are using, big visible projects like Babel and Webpack receive tons of funding because not only do a lot of people use this software but they see that they are using it. He explains that smaller projects that are buried in a stack don’t get funding because they are less visible to their users. Relating this to Unified, Titus doesn’t think Unified fits into either category. Unified is a bunch of smaller modules but is advertised as one large monolith. Which is why they get as much funding as they do.    The Starbuck’s supply chain analogy is discussed by the panel. The analogy is this, farmers grow the coffee beans to make the coffee at Starbucks. While sitting Starbucks the coffee drinkers never think of the farmers that put all the work into the coffee just about Starbucks. Some opensource projects are the farmers, small and unrecognized while others are visible and renowned like Starbucks. The panel asks Titus about where he thinks Unified fits into this analogy.    Next, the panel discusses governance, asking Titus how he decides who gets the money. He explains that in people would help out, fixing things, and Titus would tell them to send in an invoice and that he would give them some of the money. Many of the people didn’t want the money, saying it was opensource and they were happy to donate their time. Titus then decided to try maintaining Unified fulltime and has been doing so since May.  He explains all he does every day to maintain Unified. 
  “What’s next for unified?” is the next question the panel wants to be answered. Titus explains how they partnered with NDX and announced a new project...

Episode Summary The panel interviews Lou Huang, who has a background in architecture and urban planning. Lou built an opensource app called Streetmix and uses it to help the panel understand opensource projects from a user's perspective. Lou starts by sharing his background, how he got into opensource and his work making Streetmix sustainable.    Lou then explains that most Streetmix users are urban planners and don’t care if it is opensource or not. The panel weighs the trades offs of choosing an opensource project versus a non-opensource project.    Considering the benefits of using an opensource product, the panel discusses the effect opensource has on developers learning from opensource code. Convenience is mentioned and the panel touches on how seeing the code can ensure that your information stays private.    The trade-offs of using opensource are discussed by the panel. They also discuss how trade-offs are getting fewer. These trade-offs include extra time and the risk of the project not being maintainable.    The panel discusses what the word sustainability means and Lou references the Sustainability three-legged stool. The panel considers the three legs of the stool, economic, social and environmental.   How to raise awareness and funding for sustainable software. The panel also discusses why and how non-technical users of opensource products can contribute to sustaining software that they love. Panelists

• Eric Berry
• Richard Littauer

Guest

• Lou Huang

Sponsors  

• GitLab | Get 30% off tickets with the promo code: DEVCHATCOMMIT
• DevOps
• DevEd
• CacheFly

Links

• https://www.codeforamerica.org/
• http://saiko.fish 
• https://streetmix.net/ 
• https://louhuang.com/
• https://biffud.com/
• https://twitter.com/SwiftOnSecurity/status/1067682759592869889 
• https://www.facebook.com/Sustain-Our-Software-SOS-857471391289849/
• https://twitter.com/sos_opensource

Picks Eric Berry:

• https://theuserisdrunk.com 
• Unblocked 
• iPad Pro 

Richard Littauer:

• https://www.sidetracked.com 
• https://indefenseofdegrowth.com 
• https://yellowlegalpads.com ...

Sponsors

• Gitlab Commit
• Adventures in DevOps Podcast
• The DevEd Podcast
• Cachefly

Panel

• Richard Littauer

Joined By Special Guest: Chris Ward Episode Summary This week, Sustain Our Software welcomes Chris Ward, Technical Writer at Ethereum from Berlin, Germany. Chris shares his story of how he became a technical writer as well tips and resources for good documentation writing. After many years working as a developer, Chris realized he enjoyed helping others understand technical subjects. Chris defines a path of how to become a technical writer. He advises contributing to Open Source projects as well as joining the Write the Docs Society. Chris and Richard discuss why having good documentation is important and what the minimum viable documentation for a project is. Often times the assumptions that developers make are not very obvious to other developers on the project and the users. Then then discuss the common challenges a technical writer faces when creating documentation targeting developers, contributors and Getting Started Guide. A good technical documentation develops over time and like code it's never really done and newer versions are rolled out as questions come in. Chris recommends some tools for technical writing as well as a book by Stephen King called On Writing. He also recommends dogfooding or hackathons to help the developers work on usability issues. Then they talk about how the Bounties model can also be applied to documentation writing. Links

• Learn to Build on Ethereum with Kauri
• https://readthedocs.org/
• https://github.com/btford/write-good/
• Society for Technical Communication
• https://www.ethereum.org/
• Write the Docs Society
• https://gitcoin.co/
• On Writing
• https://github.com/errata-ai/vale
• https://chrischinchilla.com/
•  

Picks Chris Ward:

• On Writing by Stephen King
• Write the Docs Society
• https://git-fork.com/

Richard Littauer: