Tsikbal: from my perspective

That China it's looking into making GNU/Linux custom OS, is both something I look forward to and something that makes me worry quite a bit. The good part of China moving to GNU/Linux, is that it has the potential to make other countries to look into GNU/Linux as well. Even if not all who do look into it fully migrate to open source software, which would be the ideal thing to happen, it could mean that at least some of their IT moves to it. Like it or not, China has a lot of sway. Moving to GNU/Linux might start a domino effect not only with some of the other BRIC nations, but with people that do business with the second largest economy. Besides, since it has a population of over 1.35 billion people will have an enormous impact on the economy of scale to produce hardware that supports GNU/Linux and open source software in general. The part that makes me worry, is that China isn't known to go by the spirit of open source. Hopefully, China will see the benefit of adh...

Reading this blog post entitled Work and open source , made me ponder about how to monetize open source projects. Though he's right that not all projects are abandoned because of financial issues; the important thing is what financial issues cause open source projects to stop being maintained. While Gittip seem to be a good tool to monetize some open source projects, it might not be the answer for every project out there. For me, Gittip seems to be a better fit for those projects that individuals use for whatever reason. It gives people a way to personally tip the developers for their hard work, while making contributions bigger by funneling a large sum from different sources in a single place. Another idea I like, and agree with, would be to GitHub to help the ones who use it to monetize their projects directly on the site. By adding a monetizing service to their site, GitHub stands at the chance of becoming an even more valuable tool for developers. Neither Gittip ...

It seems that this article at arstechnica.com about KDE misses the point about whats going on the GNU/Linux camp, in a sense that it's not about the kernel itself. It's about the desktop environment. What's going on, is that there seems to be a race toward convergence. Trying to have an user interface that's pretty much the same on the PCs, tablets and smart-phones. On the GNU/Linux camp, the main example that come to my mind is Canonical's Unity user interface . The main debate it's about how best convergence can be achieved, or if something that can be done. Some argue, like KDE's Aaron Seigo at this article at themutk.com , that convergence isn't coming at all. Even though I'd like to see full convergence across all platforms, I agree that it wont happen. In a sense, I think that we'll have some level of convergence. Yet, that convergence wont be on the user interface, but on the standards used to run software so we can actually ...

As with many things in life, the hardest thing to do with any FOSS (free and open-source software) project is manage it so that it doesn't get sidetracked from it's goal and to get things done. In many cases, FOSS projects that have sound technical foundations fail because their resources where mismanaged or they lost focus because of it. Sometimes it's because of both, which is a shame. The reason why Red Hat , LibreOffice , Firefox , and even Canonical , have had the success is due they have been well managed. These companies have brought together the technical expertise and the vision, and their management have made the right choices to keep true to them. So, they have arrived to the success they enjoy now. Yet, as Mozilla has shown, finding the right people to lead the project forward can be somewhat tricky to say the least. Specially since many FOSS project depend on their communities to take it forward. In a way, the management of some FOSS projects ...

With examples of the UK government choosing the ODF standard, or Geneva bringing open source software to their schools, are victories that help open source advocates to make the case for wider adoption of open source software and open standards. In both cases, shows how the benefits are to many to ignore and are quite enough incentive to make the move. The savings on the money that has to be paid in royalties, and for the right to upgrade are considerable. Not only that, at UK case it means that people can access government information without any cost imposed to them just to look said information because they can access it from any suite they choose. As this article at cnet.com about LibreOffice points out, now people don't have to pay Microsoft for their office suite to be able to access public documents. Whats best, there are several other office suites that can be used to access public documents saved on the ODF format, while being able to handle old Microsoft'...

This article at infoworld.com got me thinking, Tizen failed because it's open source model or because it was badly managed? It seems to me that the failure of Tizen has to do more with how the project has been managed so far, rather than with it being open source software. With Samsung betting heavily on Android, and Intel getting its hands on whatever OS can make its chips relevant, Tizen really had much chance to succeed. As with proprietary software projects, open source projects success depend heavily on how the leader of the projects manage them. On both sides, there are far more projects that fail than those who become success stories. Neither development process comes with a warranty of success attached with it, since there are many factors that can determine if a project will be a success or a failure. Trying to pin the blame on the open source development of Tizen, is quite shortsighted. As it states, the failure of Tizen is more a matter of strategy than of ...

This arstechnica.com article highlights a point that I think is something of a shortsighted view of the integration of software and business processes. It's the choice between choosing to modify the software or the business processes, so that they integrate in a way so that they add value. There is no single answer, the reality is that each project is different from each other. As such, when the upgrade is being done one should map out when is modifying the software or the business process will bring the most value. In short, choose to modify the one that has to adapt to the other in order to make things work to the best of their capabilities. It's also important to have in mind that, sometimes you're going to have to modify both in order to achieve the results you're looking for at the end. That's why having a clear idea of how you're doing things, and the results you want to achieve. Only with this in mind, and fully mapped out, you can make the ...