Creating Open Source Software
Software Product Development.
Open source software
As a programmer and someone that simply uses their computer frequently, I interact with software a lot. Whether it be for programming, productivity, entertainment, or other purposes. Most applications share one thing in common: They’re powered by Open Source Software. But, why am I interested in it?
Open Source Software is a rapidly growing market and the heart of modern day software development. Over the course of the last 20 years, Open source software has seen only major growth due to the rapid expansion and improvement of the internet. As a matter of fact, you’ve indirectly used open source software to find and read this article. Companies like Facebook, Google, Twitter, Instagram, Airbnb, etc, rely on Open Source Software to operate their services that you may or may not have interacted with.
However, as great as Open Source Software sounds, I have come to think of two major problems that arise when trying to create products under this domain: Profitability, Maintenance/Direction. Let’s break each one down and examine solutions that have been used by businesses and people to circumvent them.
Profitability
For both people and businesses that develop and maintain OSS, how the heck do they make money? As you can imagine, making money off of software that is given to the public for free is a difficult task, but there are ways to circumvent it. For example, we’re going to take a look at Red Hat, an Open Source Software giant in the tech industry. As of March 2018, Red Hat has had 64 consecutive quarters of total revenue growth. So how does Red Hat do it?
According to Jim Whitehurst, CEO of Red Hat, there are only two ways to make money through OSS: “One is the public cloud model, and it’s on the public cloud offering open source as a service and then Red Hat’s model, which is to be a significant contributor and offer on premise software and drive road maps for customers, etc”. What I think Jim Whitehurst is conveying is that rather than solely providing Open Source Software as service to users, their business contributes a significant amount of code to pre-existing Open Source projects, offer software that is to be used on premise of the users or businesses computers, and “drive through” road maps that are created off of the needs of their customers.
Maintaining an open source project
Without a clear direction of what the future is like and a static group of maintainers, how does anything get done? While having software that is worked on by anyone is nice, the implications of it are not. Whether you like it or not, there is no standard of programming that fits all. Decisions are going to have to be made about how something should be done and also whether or not it should be done in the first place. Digital Ocean, A cloud platform for developers and big user of Open Source Software/Tools, believes in four specific guidelines to be set for maintaining Open Source projects.
- Write useful documentation — All projects should have good documentation. Good documentation is what’s going to allow more people to contribute to your project.
- Organize issues — Issues are features or bugs that can be added/removed/fixed within the source code. You should know how to organize, manage, and handle issues that arise during your project.
- Make contributing rewarding — Make users want to contribute to your projects. There should be clear guidelines for how developers can contribute to your project and for good measure you should keep a list of all contributors as a means of recognizing the contributors for their work in a public way.
- Build your community — Interact with your contributors and user base as much as possible. People will gravitate towards communities they feel more welcomed to be around.
Moving forward
Aside from that, making a product inside of the Open Source domain would be a way of contributing back to society and allowing it to create something potentially amazing with the work I have done. But, before I can actually create a product in my domain, i’m going to have to better understand it.
Applying PEST Analysis
In order to understand what problems were posed in my domain, I had to understand all of the external forces that drive, manipulate, or influence it. For those of you that are unfamiliar, PEST analysis is a way to quantify aforementioned forces.
Political:
- Making software that could better improve, secure, or stabilize our democracy is priceless.
- With the interference of the most recent US election, the demand for software that can prevent our elections from being manipulated are invaluable as well.
Economical:
- Businesses can bootstrap services together faster if they rely on solutions provided by reliable software.
- Can offer enterprise editions + support/perks for companies that rely on the stability of your open source project
- Donations are also a major help in driving the growth of an open source product.
Social:
- There are no secrets in open source software. Developers and Consumers can much more easily install trust into open source products since they can be audited by everyone
- Open source software allows anyone to contribute to big projects and give back to society.
Technical:
- Open source software helps create generally better software.
- Security issues can be reported by other people contributing/auditing your code.
- Reliability is much easier to insure over closed source counterparts.
With all of this in mind, we can now better scope out the domain of Open Source Software. However, these forces only influence the market. What we need to do now is analyze the businesses that occupy it.
Applying Competitive Analysis
Competitive Analysis is a tool that we’re going to use to help us understand exactly who is occupying the Open Source space and how they’re doing so.
Let’s look at the top 20 companies that have employees contributing to open source software.
Interesting. Microsoft, a company that’s business model operated selling closed source software for so long, has the most employees contributing to open source projects. Another thing to note is that all of these tech companies use tech stacks that are composed of Open Source Software. This reliance on open source software creates an incentive for companies to have their employees directly or indirectly working on these projects. With these insights, I am now ready to start creating and conducting user interviews.
Conducting User Interviews
To better understand the domain and the demographic of it, I conducted some user interviews that yielded some pretty interesting results. Before discussing the results, here are the questions that were asked to people to help understand their perception of the field.
- How often do you use a computer?
- Is there something specific that you use it for?
- Is there something that holds you back from using it more?
2. What is software that you frequently use but have to pay for?
- Is there a feature you wish that software included?
- Do you think the price of the software is reasonable for what you get?
3. How much do you trust the software that you use?
- Is there anything that would make you trust it more?
- Is there any event in particular that has made you lose in software?
4. How important is software reliability to you?
- What are pieces of software you’d consider reliable?
- What makes that software reliable?
- Do you have examples of software you just couldn’t use because of how unreliable it was?
5. What is a tool that you or your team use and pay for but feel that it’s capabilities are limited?
- Is this tool use mandatory?
- What makes it feel limited?
- Have you tried to seek out alternatives?
When I had asked people these questions, not all received the same sub questions to the 5 main questions I asked due to the different responses I received from people. What I found is that Open Source as a domain is a relatively narrow space. Although many people interact with Open Source Software, very few people that weren’t developers knew exactly what it is. The ones that did had a very limited knowledge of what went on behind the scenes.
Conducting user interviews helped me discover that targeting businesses instead of consumers might be a better business model for trying to create a product. Since limiting the scope of whom I develop my product for is risky, I contacted a friend from the tech industry to get his opinion.
Talking to someone in the industry
To get another perspective about Open Source Software, I contacted an experienced senior product manager. Awaiting response, I asked him 4 questions:
- How often do you use or interact with Open Source Software?
- How has Open Source Software molded the services/projects that you’ve worked on (both personal & at work)?
- What do you see in the future for Open Source Software?
- Is there any piece of Open Source Software that you couldn’t imagine doing work without it?
I’m excited for his response and incite to be shared about my domain.
My product
With everything that I have learned, I feel confident in my ability to attempt to make a product and to that solves a useful problem for the world. As a programmer, I’m an avid user of git & github. For those of you who don’t know what either are:
git is a version control system for writing software applications.
github is a platform for hosting, interacting, and providing data for or about those systems.
While github is great, there are some features that don’t quite satisfy me:
- both the general user data and analytics provided by their platform aren’t aggregated into one place that’s easy digest.
- while they do provide insights, the insights provided aren’t as useful as they could be.
- Tracking organizations and it’s teams members isn’t as advanced as it could be.
My product is hopefully going to fix that. The general idea is an open source desktop/web app for tracking more useful data, analytics, and insights on both users and organizations on github. Before I can develop this product, I’m going to need to think more about what exactly my users are going to interact with my page.
User Journeys
User journeying is a good way to specify how a user is going to interact with your app. It gives you the perspective of being an actual user trying to go on your product and use it. Here are a few that I created for the scope of my app:
“I’m Faith I push to github A LOT! Upon browsing Reddit, I found out about a website called gitfor.me. It’s a tool that is used to make useful insights about your activity on github. I logged in with my github account to register my account for being tracked. In a couple of days, I was able to see my github activity in a completely new perspective!”
“I’m Timofey and I wanted to know how many commits my team has pushed this month. I went on to gitfor.me, logged in with GitHub, and then was brought to the team section. I am in multiple teams, so I searched for the one that was relevant to me. Upon finding my team, I was able to see what they were working on for the week. ”
“I’m Max, and I’ve been a gitfor.me user for a long time. However, I’m not sure if I some of the statistics and insights are really that relevant to me. I went to the settings tab, and disabled pull requests from being displayed throughout the website.”
With these user journeys in mind, I now feel confident enough to start wire framing.
Wire framing & what I learned from it
This was my first time ever wire framing something that I was going to create. I didn’t really know what I had in mind for a design upon going into this, but I came out with what I think a satisfying design candidate for my MVP and the knowledge of the importance of wire framing.
While designing my product, I was able to prototype out it’s UI very quickly. Any changes that I made and didn’t like weren’t permanent and something that took only seconds to fix. If I were to have went straight into building this app, I would not be able to guide the design on if as smoothly as I did wire framing it.
Down below are all of the pages of my app that were encountered with in the user journeys.
Conclusion
I am excited to use the knowledge I have learned throughout this course of the last two months in solving real world problems. With both a technical and nontechnical skill set, I now feel confident in my ability to produce applications that can solve real world problems. Within the next week I will start and finish the construction of my first deployed app, gitfor.me. Although the app might not be in it’s best possible version within this time span, I’m excited for the future of the project. As an aspiring software engineer, this application will provide a great learning experience as well as a way to showcase my skills.