Reflections on Open Source in Today's World

Due to the power situation of last week, and it only being restored on Monday, I have not had adequate time to build Freeciv on my Linux box. I do have experience in building and making executables on Linux, but I will attempt to get around to this assignment later if possible.

 Luckily, I did have time to read two articles from http://opensource.com/ .

The first article I looked at was about how Linux will grow in the mainstream market. It starts off by stating quite obviously that in the OS market Linux doesn't even exist to most people - they only know about WIndows and Mac. I have to agree with the assessment that one reason people do not know about Linux distributions is because they don't know of a PC they can buy that comes with one installed - they all have Microsoft Windows or Mac on them.  The closest thing that comes to that in the mainstream market is the recently launched Chromebook.

He states that most people are happy with theirs, with the exception of it's ability to produce video and manipulate images. The Chromebook isn't really designed for this, and he suggests some fixes. Honestly, I do not know anyone who would have one for anything other than note taking or other portable functions - as everyone I know wants to be able to do more memory and CPU intensive things.

His opinion on Ubuntu seemed to be that it replaces Windows well enough, but has a problem with the web-cam software. He had similar problems with Mint, the only difference seemed to be that those that are more familiar with technology would prefer Mint.

 All in all, I was disappointed in the article as I was expecting more business discussion, but it was still a somewhat interesting read. Given that I already knew of Mint's existence and that it was slightly cleaner and faster than Ubuntu, I learned nothing other than the most popular webcam application doesn't always work. Useless information to me really, but information I now have none the less.


The second article I looked at was about how 3D printing could improve interest in open source material. I have a significant interest in 3D printing as a consumer, but have more pressing issues to think about most of the time. I did like and agree with the point that companies already sell products for really cheap (in comparison to the production cost) - and almost give them away for free - in terms of printers, video game consoles, and even razors. They do this so that they can sell that which goes with the product - applications, video games, razor blades. In terms of doing this by giving the initial blueprint to a device, and then selling accessory blueprints, it makes a lot of sense. I can somewhat see his vision of the goods becoming worthless in comparison to it's personalized data and connection to the internet, but I think this is quite a ways off indeed - even if we all had 3D printers tomorrow. I think this will be accelerated mostly by the fact that if 3D printing gets really big, then everyone will have the data necessary to create what they want - the product itself won't be valuable, but what makes it work correctly will be.

Bug Juice

As previously stated, our team has actually fixed one bug already. It was a graphical glitch involving  about:firefox being wider than it was supposed to be. Our full experience report involving this bug is contained in the url below. We already have another bug being worked on at the moment, which involves removing unnecessary comments from tabs. More information is at the same page.

We are currently looking into more bugs and improvements as we do not expect the second one to take terribly long to fix.

The rough timeline is also up on our wiki page, the link to which is below the link to the bug link. This timeline is very rough and subject to change.


Bug Link

Timeline Link

Deliverable 5 - Part 1

We met today at our normal time to finish our project. We had code changes, a presentation, a poster, and various other things to be done. This enabled us to have a nice division of labor for completing things simultaneously. I personally tried to work mostly on the final document that was to be handed in.

We got everyone started on their part of the final project. Most of the presentation was planned, the document was mostly done and outlined, and the poster progressed greatly. We plan to meet again on Tuesday to finish up everything and do our practice presentation runs.

Final Meeting on Deliverable 4

This meeting we are finishing Deliverable 4 and the patches to deliverable 3 required. We tackled the problem with ordering of file names easily, as we did with getting the html output file to open automatically. All of our tests were already created, so that was done. Our output still isn't that pretty, but it's readable. We're gearing towards deliverable 5 already by planning everything out.

Meeting on Deliverable 4

We met again on Sunday in order to do the bulk of our work on Deliverable 4. Deliverable 4 was simple in principle - fix the problems with the third deliverable, and add another 15 test cases in order to obtain 25.

We started to develop a majority of the code changes to deliverable 3 that we had previously sketched out. We fixed our documentation for deliverable 3 and finished most of the documentation for deliverable 4. If the code we plan to implement doesn't work properly we'll have to go back and fix these changes, but at the moment it is theoretically sound. Coming up with the extra 15 test cases wasn't difficult at all - we incorporated another method that compared strings (by checking if the second string was an exact component at the beginning at the first one). We went back and added two test cases to our previous method as well. We'll meet again before our deliverable is due to solidify any code changes that haven't been finished by then and rework any documentation that needs to be gone over again.

Chapter 24 Thoughts - Quality Management

Having a good structure for a quality assurance plan seems important to the process. Without documentation it's harder to keep the same level of quality assurance constant - it is unlikely the entire quality assurance team is going to have the equivalent of a modifiable document memorized.

Having clear requirement is obviously important to the quality management process. Without requirements there isn't a measuring stick for quality assurance processes and standards to measure up against. Speaking of standards, software standards should be met whenever they apply to the situation.

Inspections and reviews was an interesting section to go over. It's more than just normal testing and seeing if the project works within specifications - it's about potential problems and measuring quantitative relationships and statistical information on the code itself.

Impromptu Meeting To Fix Deliverable 3

Today Nelson, Crendall and I attempted to fix at least some of our deliverable 3. The fixes we included were changes to the code and generalizing the test generation, as well as changes to the document. Changes to the document included things such as names, date, context, and filling out in greater detail how our tests work. Test cases requirements were specified further than reference,  and the how-to section was revamped all together to specify how to add and remove tests as opposed to how to run the framework in general.