Web In Progress – second phase

Below are the projects in the second phase of the contest:

• AirJobDone – Andrei Dulceanu (Apache License 2.0)
• Face Recognition for Mobile Phones – Octavian Sima, Elena Holobiuc (BSD license)
• Image gallery – Silvia Elena Stanculescu, Alexandru Dobre
• LabRemote – Ioan-Alexandru Eftimie, Sergiu Iordache, Irina Preșa (GPL v3)
• Plant Care – Sinziana Mihaela Gafitanu (LGPL)
• Thematic chat – Marius-Tudor Benea (Modified BSD License)

I will come back with more details and links to projects.

Web In Progress – proposals

As promised I said I’m back with some project proposals for the WebInProgress contest. Please keep in mind that these are merely some examples, you can register your own proposal.

1. Mobile VNC server – Implement a “lightweight” VNC server for mobile. What “lightweight” means must be defined.
2. XSidebar – Implement an easy customizable/scriptable cross-browser sidebar. This is not part of a specific web page, but augments the web browser. It is usually implemented as web browser add-on.
3. RSS mobile widget – a mobile widget (not standalone application) capable of displaying an RSS feed.
4. Rendering engine in Firefox – implement a Firefox add-on that will integrate different rendering engines like IE (multiple versions), Webkit or Opera in Firefox. A project can implement only one rendering engine, and ideally all the projects will be interoperable.
5. Anti-spam application for mobiles – an application that will block spam (SMS, email, instant messages) for mobile. This will integrate with a community anti-spam server.
6. SyncML for bookmarks – define a SyncML protocol for bookmarks and implement it for mobile and/or major browsers.
7. Mobile gallery – an image gallery that works with different source like local images, Flickr, Snapfish, Picassa, Google Images etc. New sources should be easy to configure and add.
8. Mobile/desktop/web reporting widget – a widget that will display a chart (pie, bar etc) aggregating data from web services. The widget will be implemented on a mobile platform, desktop or within a web page.
9. XSLT browser add-on – a browser add-on that is applying an XSLT and displaying result on-the-fly for the current tab.
10. VoiceXML mobile browser (hint: leverage mobile voice recognition and speech synthesis capabilities of the device)

And in the end a few considerations for all the proposals

• For mobile applications the following platforms can be used: Android, webOS or any other major one. For a project, a team can consider only one implementation. It would be ideal that all the implementations (even from different teams) be interoperable and offer a similar user experience.
• For browsers add-ons the following browsers can be considered: Firefox, Internet Explorer, Chrome and Safari.

Web In Progress – registration and rules

The contest is open to students in the technical field from Bucharest universities that love to develop open source applications for web and mobile.

To participate in the contest you must register yourself or your Team by e-mail until July 20, 2010. Send an e-mail to webinprogress@hp.com that will include

• Your name and all the names of your Team members (up to three including yourself)
• A Curriculum Vitae of you and all of your team members
• A title and description of maximum 5000 words for your application (App) proposal
• The open source license under which the App will be submitted and developed
• The reason for participating in this contest

You will receive a confirmation e-mail until July 25, 2010 if your App proposal qualifies for the contest and you can move to the next phase.

The complete contest rules can be found here.

WORKING AREA! WEB IN PROGRESS …

We are WEBINSANE, WEBINSPIRED, WEBADDICTED. What about you?

Wednesday, 30 of June, at 11:00, in University of Polytechnics, the contest “Web In Progress” was launched. This contest is sponsored by Hewlett Packard and is addressed to all the students (and graduates from 2010) from Bucharest universities that love open source, web and mobile. You are invited to develop an open source application in the web and mobile area.

You can view (or review) the slides from the live presentation.

I will come back with rules, registration process and project proposals. Stay tuned!

Roles in Open Source

Following my presentations about motivation and success in open source, comes a new one about the roles and life cycle in open source software development. Before going into details, I would like to thank Laura and Razvan for arranging this.
I have to say that I was pleasantly surprised, that the students have at least basic theoretical understanding about the software development process and roles involved. I will describe briefly the steps in this process. Please keep in mind that these steps should appear no matter what development methodologies you are using (waterfall, iterative etc), but they can differ in length or importance. The important part is the outcome, any of these steps can be viewed as a black-box that, given an input generates an output.

• Initiation. The first phase of a project after which we will end up having in our hands, the IDEA, or more formally a short description of the project. As opposed to a commercial product, where this comes usually from a business need or a client request, in open source, more often this will be (hopefully) an innovative idea. The owner here is the initator. If this comes from an internal business need, it can be called sponsor or from an external request, client.
• Economical analysis. Having the idea, a market research and/or feasibility study will follow. Intentionally, I used “economical” instead of “financial”, because unlike commercial products where profit is the main criteria, here other success criteria can be investigated and considered. This phase will answer to the question: “Should we start the project?”. The one that creates the documentation containing all the information for answering such a question here is the economical/financial analyst, but the initiator will give the final answer.
• Planning. And the answer is “Yes”, we have a project. The project manager will create the project plan, assemble the team, establish initial timelines. Its role starts here and it will continue throughout the entire project life, driving progress through all the other steps. In open source projects, it is harder to assemble a team and have a strict timeline. That is why the project manager role is ignored. Wrong. In an open source project, a PM has its value and in my opinion is the one of keeping the FOCUS and moving forward. With a clear mission in mind and keeping track of the current activities, he can discard undesirable actions that will make the project go on a side track and the team lose the focus and interest.
  A higher overview role here is the product manager.
• Business analysis. Starting with the short description from the first phase, business analysts will conduct sessions where subject matter experts are involved and will gather the functional requirements. These can be formal documents or user stories like in agile development. Subject matter experts are usually non-technical persons that can offer valuable information about the domain of the application. E.g. in a medical software, the medical personnel can assume this role here.
  Unfortunately, this role is usually overlooked in open source applications. That is happening because technical people like to start getting the job done and minimum knowledge is considered enough. Another reason is that SMEs think that, if being non-technical, they cannot involve in open source software applications.
• User interface design. There are lots of products that assured their success with a friendly user interface. Do you think a psychologist cannot find his place in the open source software world? Think again and your project could be a hit.
  Of course, if you’re developing a SDK you may want to skip this step.
  The output of this step will go into the functional requirements.
• Architecture. So far we haven’t been technical. Now it is time. The architects will use the functional requirements to create the technical specifications. These will define the entire system, infrastructure, technologies involved etc. Usually the architect role is assumed by a senior developer. Nothing wrong with that, but on a bigger project you may want at least a second opinion. By architect I refer to all kinds: solution, database, network etc
• Development. Finally at work :). Using functional and technical specifications, the developers will do their magic and transform them into a working application. Besides developers, we can have here working together web/graphic/media designers. Maybe now it is a good time to mention another role: functional manager. A bigger team, usually homogeneous, will also need a lead. His responsibilities will be to split the tasks to a finer granularity, provide guidance, be a reporting entry point etc. This is not only applicable to a team of developers, but could extend to teams of architects, project managers, business analysts etc. In open source projects moving to such a position will have as ground, meritocracy criteria, such as involvement in the project and knowledge.
• Quality assurance. An undesirable and hated step, maybe because it is done by the wrong people, the developers. The ones that will probably repeat the same mistake from the development phase during this phase too. That’s when testers are coming to the rescue. But the ones that really put things in order here are the test case writers. Having a test case for your application will save you of many headaches: it will ensure that you will not miss testing a feature, testing can be assigned to lower qualified personnel, bug reporting becomes easier and the list can go on.
  Even though this step is described after development, it can start even before architecture. Test cases can be done using as input the functional requirements. Running the tests tough will happen after development. But even this can be modularized and parallelized.
  This is the paradigm of Test Driven Development, even tough that refers more to unit testing.
• Implementation. In this phase we are talking about documentation, advertising and distribution. We have a final product and we deliver it to the customer.
  Documentation. It refers to user manuals, tutorials, demos. It is not the technical documentation created during development phase. The content is created by documentation/content writers, but the presentation is made by (graphic/media) designers.
  Advertising. An important factor in the success of every project, open source or commercial. In open source, innovative low-budget ways of promoting must be find and implemented. Viral is one of the key words here.
  Distribution. It includes different aspects depending on the nature of the application: packaging, installation, infrastructure. Documentation also plays an important role here.
  Don’t forget about sales. What? Sales in Open Source? Yes. Many business models are built on top of open source products. Either you offer paid support or enhancement development, you need the right people/skills to move the project forward.
• Maintenance. This is an ongoing phase and many projects were successfully because they mastered this step. Responsiveness is a must, I would say. Either we’re talking about bug fixing or technical support. Fortunately there are a lot of online tools that can make our life easier. Selecting the right one for you and your users, is not always the easiest thing.
• Finalization. Or in other words, retirement. A question is usually rising: “Do we really need this?”. Yes. If a project becomes obsolete, don’t just ignore it. State this in the official documentation and point to an alternative. It will make your users happier and save your community.

See how many skills are involved in creating a successful software system? Everyone can volunteer and find their place in the wonderful world of open source. It’s up to you to contribute and spread the word.

Success in Open Source

After my presentation about Motivation in Open Source, I had another one, this time even more focused on Open Source. I included, besides the motivational factors, the success criteria for an open source project, the driving factors to success and some adoption guidelines.
Also an interesting topic was the debate if to start a new open source project or join an existing one.
And if we talked about open source, what would have been more appropriate than an open presentation? (Open here is just another pretentious word for interactive). So, this is what we came up with.
Before reading below remember that in open source, everything relates to COMMUNITY SHARING KNOWLEDGE. And when we talk about community we have to divide it in two: users and developers. Here developers doesn’t mean exclusively software developers, but the ones that are giving the knowledge and users are the ones receiving it.

Success criteria

If for a commercial product, the only success criteria is the profit (or some other financial indicator related to it), in an open source project things are a little bit different.

• Product functionality and quality. The obvious. The final product must do what’s intended to do and must do it well.
• Community size (both of users and developers). When evaluating this you have to take into account the percentage of the target audience. If 5000 users represents a serious number for, let’s say, a Java or .Net framework, this will be disaster for a browser.
• Community quality. This is more related to developers, than users. And that’s because quality people can create quality products.
• Community energy or how active it is. If people are investing a lot of time and effort in developing and using something, most probably that something is worth.
• Revenue. Intentionally I didn’t write profit here, because an open source community could not be profit oriented and could reinvest their entire revenue into the product itself, driving its development. But if people are giving money (in any way – paying for support, donations, buying promotionals) for something that was meant to be free, that it’s definitely worth it.

Driving factors to success

• Goal. Your project must have a clearly defined and achievable goal. If it’s not well defined than you will not know what to do and if it’s not achievable you will just lose the enthusiasm and energy because you will never get where you want. It has to also be defined as long term and short term. The long term should be simple, usually compressed in one phrase (aka the mission) like: “Create a media player with 5% market share” or “Create an open-source alternative to SharePoint”.
• Structure. Your community (and your project) must be well organized. Hierarchically and functionally. Doesn’t matter what kind of hierarchical structure you have (cathedral, bazaar, matrix, waterfall etc) but you have to stick to it. Also keep in mind what functional roles do you need to achieve your goal. If you want to “Create a media player with 5% market share” and you don’t have anyone with some degree of experience to handle the (online) marketing part, that’s a gap.
• Focus. Always stick to your mission and don’t go sideways, whatever factors are driving you that way.
• Marketing. A strategy in this matter is not optional. Either you want to create awareness, increase the adoption or expand the development community.
• Business model. This is how you will generate revenue for your project, because generating revenue for your project will only help you driving it further. Choosing a business model can come later in the way, but having it from the beginning will only make things more clear.
• Functionality – Quality – Accesibility. These are not trade-in’s in an open source project. Your product must do what should do, must do it well and must be easily reachable by your users.
• Innovation. If you come up with something new on the market, your success is not 100% guaranteed, but your chances are totally boosted.
• Future. If you earn the trust of your users in your project future, then you will also gain their fidelity.

You can read the presentation (in Romanian) or view some photos.

Again thanks goes to Razvan for offering me this opportunity.

Motivation in open source

I responded to Alex’s invitation and I gave today a presentation to a few students about motivation in software development. I hope they liked it and found it interesting.

As my focus was mainly on discussing about open source projects, while I was preparing my presentation, I made a thinking exercise. And I noted down the motivational factors for developing open source applications. Let’s go through the list.

• Passion. Remember that most of you are working in this field because you like it. Sometimes developers get to work in a company and in a project that they actually don’t like. Open source is their chance to do what they like. So, even tough this takes extra time and effort, the moral satisfaction pays it off. Keep the fire burning with Open Source!
• Educational. Working in an open source is the best way to keep you up-to-date with the latest technologies. Due to economical reasons, the projects developed in closed profit-based organizations, are not up-to-date with the last technologies. Keep learning with Open Source!
• Portfolio. What you developed as open source could be a very good showcase to obtain a better job. If you don’t have yet industry practical experience, this can compensate. Show off your Open Source!
• Status. There is a special pride of being a member in a successful open source community. Be proud with your Open Source!
• Networking. Working in open source communities is a great way to meet developers, designers etc that share common interest with you. Get together in Open Source!
• Need. This is actually one of the main reasons for developing open source applications. Either there isn’t a software solution for your problem or it is too expensive, you can always make your own or contribute to other people effort to do it. Use Open Source!
• Influence. This is somehow related to need. Because a company is needing some features in an open source application, they encourage their employees to take an active role in the development of it. In this way they can easily influence the direction in which the open source project is heading. Influence your Open Source!
• Altruism/Knowledge sharing. Some people simply do it because is the right and moral thing to do. They used and enjoyed open source and now it’s time to give something back. Share by Open Source!
• Quality. I know that it may sound like a paradox, but I really think that a successful open source project has a higher quality than a successful closed, private one. Usually an open source project has a more varied and wide pool of users. It means that it also have a wider pool of critics. And they will review not only the final products, but the source code too. Moreover, the commercial products will have to constantly improve because of the competition. Improve Open Source!
• Economical. Open source is not entirely free. And here we have to talk about cost reduction and profit.
  Cost reduction. A company can develop a project, but due to the lack of resources, they decide to make it open source. If the project is not on their portfolio, but it was merely developed as a library for other projects or to support the internal infrastructure, this is a very good choice. Their business won’t be affected, but their winnings could be huge. In the first place, they win a huge amount of users, which are actually free ad-hoc testers. As the project is growing they can also gain developers or other specialists (like designers or documentation writers), thus tremendously decreasing the maintenance costs.
  Profit. A new business model has lately emerged. The organization is offering the product for free, but they are charging for related services, such as support, development on request or even specialized documentation (like books) etc. More and more companies are moving from a product oriented business model to a service oriented business model.
  Win with Open Source!

I also attached the presentation, but it is in Romanian. If you’re really interested I can translate it in English as well.

Enjoy Open Source!

P.S. Thanks to Alex and Razvan for giving me this opportunity. Thanks to Monica for recommendation.