Commarch Report

Resources:

Source Code repository: 

https://github.com/jcbrand/converse.js 

Mail list archive: http://librelist.com/browser/conversejs/ 

Documentation: https://conversejs.org/docs/html/index.html 

Other communication channels: jc@opkode.com

Project Website and/or Blog: https://conversejs.org/

A. Describe software project, its purpose and goals.

Converse.js is a chat client that runs on a browser as a JavaScript-based plugin, allowing site visitors to chat using the XMPP protocol.

B. Give brief history of the project. When was the Initial Commit? The latest commit?

The first commit to the project is on June 10, 2012 by jcbrand. Issues are regularly fixed and new features are added occasionally.

C. Who approves patches? How many people?

jcbrand act as both the project manager and contributor

D. Who has commit access, or has had patches accepted?  How many total? 

 About 10 people have made significant changes to the project that have been approved by jcbrand

E. Who has the highest amounts of "Unique Knowledge?" (As per your "Git-by-a-bus" report. If there is a tie, list each contributor, with links if possible) 

 jcbrand 

F. What is your project's "Calloway Coefficient of Fail?"

 The project passes Calloway Coefficient of Fail with flying colors, with a total score of 0.

G. Has there been any turnover in the Core Team? (i.e. has the same top 20% of contributors stayed the same over time? If not, how has it changed?) 

 No, the core team has not changed(jcbrand in this case) However, a few developers have become active in the project at different times. 

H. Does the project have a BDFL, or Lead Developer? (BDFL == Benevolent Dictator for Life) 

jbrand again

I. Are the front and back end developers the same people? What is the  proportion of each? 

 Yes, everything is handled by the same person 

J. What have been some of the major bugs/problems/issues that have arisen during development? Who is responsible for quality control and bug repair? 

A major bug existed in the project is that Converse.js sometimes empties the contact list and crashes the browser occasionally when a user is trying to load a huge amount of contacts.The problem is later fixed by jcbrand

K. How is the project's participation trending and why? 

There were a few major spikes in the code frequency graph on github early last year, but since then additions have stabilized and jcbrand seems to be making regular updates to the code.

L. In your opinion, does the project pass "The Raptor Test?"(i.e. Would the project survive if the BDFL, or most active contributor were eaten by a Velociraptor?) Why or why not? 

No, jcbrand almost is the only permanently active contributor and if he is eaten by a Raptor, a new developer will have to take over the project. 

M. In your opinion, would the project survive if the core team, or most active 20% of contributors, were hit by a bus? Why or why not? 

No, for the same reason that it fails the Raptor Test. 

N. Does the project have an official "on-boarding" process in place?(new contributor guides, quickstarts, communication leads who focus specifically on newbies, etc...) 

Yes, the documentation provided explains requirements, features, development details and troubleshooting solutions and is very easy for newbies to get started.

O. Does the project have Documentation available? Is it extensive? Does it include code examples? 

Yes, the documentation is extensive for developers, users and all newbies.

P. If you were going to contribute to this project, but ran into trouble or hit blockers, who would you contact, and how? 

jcbrand who will be available on the mailing list and GitHub issue list.

Q. Based on these answers, how would you describe the decision making structure/process of this group?  Is it hierarchical, consensus  building, ruled by a small group, barely contained chaos, or ruled by a single or pair of individuals? 

 The project is ruled by a single individual

R. Is this the kind of structure you would enjoy working in? Why, or why not?

 Yes, the size of the project is relatively small and simple. This helps up to spot bugs easier and communicate with the project owner(in this case).

Team Proposal

Team Members:


Name               |  Email


Tom Conroy     |  tdc5536@rit.edu


Anjali Tewari    |  axt6472@rit.edu


Danny Nguyen |  dxn7335@rit.edu


Lanxi Xing        |  lxx4650@rit.edu


Which project did your team choose?


Our team chose to research https://conversejs.org


2-Liner Description of the project?


Converse.js is a light-weight, open-source browser-based XMPP / Jabber chat client. It allows users to have a custom, private and secure chat integrated directly into their website.


What will each team member's role be?


Tom Conroy  : Coordinator, Developer (Front-End)


Anjali Tewari  : Documentation, Developer


Danny Nguyen : Documentation, Developer (Front-End)


Lanxi Xing   : Documentation, Developer


Source Code Repository URL:


https://github.com/jcbrand/converse.js


What are the easy parts?


Gathering project information ( contributors, commit logs, documentation etc. ) as it is all easily available on github. 

First Bugfix on Twisted

Gratz to my self – this is the first bugfix I committed on an open-sourced project. Twisted is an event-based framework for internet applications. It includes modules for many different purposes including a general credentials and authentication system that facilitates pluggable authentication back ends. In short words, the project needs to keep track of the licenses using code (python in this case).

The ticket that brought to my eye was about fixing the string for some constants and find a way to expose some of them to other classes. I picked it because I thought this could be an easy fix and also a good place for me to start contributing to a project at some level.

Soon I started to go through the READMEs and other documentations for me to get started and then I realized that I was wrong. An easy bugfix might actually require a decent knowledge about the project in order for you to fix it. After I submitted my first pull request, I had to first get the part that I'm working on and then find the correct documentation that I am looking for in order to correctly understand what is actually going on with the code. This is also the reason I’m still stock with second part of the bug right now. I will keep in touch with the ticket author in order to have some more progress on it.

One of the biggest lesson I learned is that in order to fix a bug (even for the smallest bit size), you will still have to go through a huge chunk of the project for you to just get started. Another thing is that people who are in the community are actually nicer than I thought. Some of them might not be too helpful but they’re still at least being responsive and friendly. I’m looking forward to be more involved into these kinds of projects and communities.

RocPy Meet up 9/16

This is a post about the Roc.py meet up on last Tuesday (9/16). RocPy is a Rochester Python User Group who often actively contribute to many open-sourced projects.

The meeting I attended was “an open course on open source about openshift”. Many technologies behind the scene were introduced including how Flask, YAML and OpenShift work plus how the group is using GitHub to keep track of their code.

Additionally, a list of readings were introduced to us who recently just started HFOSS activities. I found many of them to be not only helpful but also interesting. “The Python I Would Like To See” – written by Armin Ronacher was the most interesting one to me. Without talking too much into the design / logic used by Python, the bright point I picked up is the reason why people would to join open sourced projects. This is because they know that the project is not perfect and they want to contribute as much as they can to improve it. Same idea was also introduced during the RocPy meet up - which was quite impressive to me.

Here're some other readings I found to be quite useful for FOSS beginners that are also introduced during the meet up:

• Unpythonic Python
• Distributing a Python command line application
• Full Stack Python
• Math evolution and dirty tricks

Even though I did not understand a decent amount of topics they're talking about, but it is still interesting to me and brings up my memories about Python since I haven't used the language for a long time. I'm looking forward to attend more of the RocPy meeting in the future.

Quiz 1: The Success of Open Source & The Open Source Way

This is a in-class quiz regarding to the reading of What Is Open Source and How Does It Work? and The Open Source Way

1. What are the titles of each Pillar?
• Open Exchange
• Participation
• Rapid prototyping
• Meritocracy
• Community
2. What are the titles of each General Principle?
• Make it interesting and make sure it happends
• Scratch an itch
• Minimize how many times you have to reinvent the wheel
• Solve problems through parallel
• Leverage the law of lager numbers
• Document what you do
• Release early and release often
• Talk a lot
3. What are the similarities between Weber's eight principles, and the five pillars?
• Both the eight principles and five pillars explained the reason of why people would be involved to the open source projects. They also explained how and why people in the community would work together (both Minimize how many times you have to reinvent the wheel in the eight principles and Open Exchange in the five pillars).
4. What are the differences?
• Weber’s eight principles focused more on how important it is for the communication to work together while the five pillars are more general about what makes the open source work. Additionally, Meritocracy in the five pillars also was no directly mentioned in Weber’
5. Bonus: Who's "keen analysis" did Weber "Draw Heavily" upon?"
• Eric Raymond
6. Double-Bonus: What was the title of this "keen analysis." (Hint: Weber hinted at the title when he was talking about Cathedrals earlier in the chapter.)
• The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary
7. Triple-Bonus: Where can this keen analysis be found? (Answer in URL form, i.e. http://placeofkeenanalysisis.com/analysis)
• http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/

Lit Review: What Is Open Source and How Does It Work?

This is a literature review on Chapter 3 of the book "What Is Open Source?" that is written by Steven Weber. The book is published in 2004. The book describes the establishment of open source and how it has evolved over the past fifteen years.

Weber used many statistics describing how the population of the contributor rapidly increased along the way. Additionally, he made his point that a good project does not come off from one person's mind. "The key element of the open source process, as an ideal type, is voluntary participation and voluntary selection of tasks." This is the most interesting line to me throughout the reading. I believe this is the core of the whole open source process - there must be something attractive to people that keeps them from working on these projects.

Goods:

1. The book (specifically chapter 3) is generally straight and forward. Weber did a good job explaining how things have evolved throughout the years without making the connections between each projects too complicated.
2. Used many statistics to proof his point such as the rapid growth and strong background of open source projects.
3. Provided a good reason of why people are voluntary involved into these project. Reasons include: attractive and motivative projects, challenge for all of the programmers and etc.This answers my question such as why payback would people contribute to projects without asking for paybacks - I was quite impressed by such the passion of these contributors.
4. Situating everything into "problems" and described how everything is been "solved". Additionally, Weber introduced the people who contributed to the projects. It's nice to know the big problems we had back in the day and people who made some big steps to contribute.

Bads:

1. The book focused too much on some of the big projects such as Linux
2. Weber included too much background stories for each projects / contributors which is relatively boring.History is clearly not the case for a industry (industry?) that evolves in such a fast speed.
3. Should focused more on how things are been solved instead of why they should be solved.This greatly slows down the pace of the book.
4. Since this book is published in 2004, many information are now outdated. This is however not a criticize of the book though.

Overall the book is interesting and fun to read. The proof and stories about the projects, people and phenomenons are all solid, supportive and real.A great introductory book for open source software.

First Flight on HFOSS!

I'm Lanxi Xing (xingnx), this is my first post about learning HFOSS. HFOSS is a brand new field that have not been visited before - and I'm extremely exciting to start learning it.

Starting with IRC, I logged into freenode IRC and installed HexChat lately. It is a really useful instant chat room where you can keep in touch with others regardless whether they are in your class or not. This makes the learning environment extremely open and free, which you can often get both positive and negative feedback.I believe this learning environment can help me and other students to achieve more since there're more people who reviews them and they are willing to give you any kinds of feedback.

Blogging is a very important method to keep track of your own tasks and achievements. I will be posting on this blog every week to write down my successes and failures. Additionally, this will also be one of the methods for me to get help and knowledge whenever I'm stuck on developing. I'm looking forward to discover more on Blogs.

That been said, installing Github was one of the first challenges I ran into. I was stucked with Git Bash (git terminal) for a long time due to the permission error I ran into when I tried to clone a repository. This keeps me from doing everything after clone until today. I found out that there is actually a GitHub GUI I can install and make my life so much easier.By using the GUI, push and pull requests for my .yaml file was much easier. However, I would still like to learn how to do everything from the terminal due to the nature of programming where you will have to know how exactly everything worked.

In general the first flight went pretty well. I am excited that I have stepped into a field that I've never known before. I will post