RDFBean interfaces and dynamic proxying

Along with traditional JavaBean-like persisting technique using RDFBean classes, the version 2.0 introduces new approach to object-RDF mapping: RDFBean interfaces.

It works simply: you define an interface of your domain model object and annotate it just like an RDFBean class:

@RDFNamespaces("foaf = http://xmlns.com/foaf/0.1/")
@RDFBean("foaf:Person")
public interface IPerson {
 
    @RDFSubject
    String getId();
 
    @RDF("foaf:name")
    String getName();
 
    void setName(String name);
 
    @RDF("foaf:mbox")
    String getEmail();
 
    void setEmail(String email);
}

Then you instantiate the RDFBeanManager (was RDFBinding in RDFBeans 1.x) upon an RDF2Go Model and create a dynamic proxy object with your interface:

ModelFactory modelFactory = RDF2Go.getModelFactory();
Model model = modelFactory.createModel();
model.open();        
RDFBeanManager manager = new RDFBeanManager(model);
IPerson person = manager.create("http://example.com/persons/jdoe", IPerson.class)

The methods of this proxy object are directed immediately to the underlying RDF triples, so that

person.setName("John Doe");
person.setEmail("john@example.com");

will cause adding the statements to the model:

<http://example.com/persons/jdoe> a <http://xmlns.com/foaf/0.1/Person> ;
	<http://xmlns.com/foaf/0.1/name> "John Doe" ;
	<http://xmlns.com/foaf/0.1/mbox> "john@example.com" ;

Similarly, the getter methods will return values retrieved directly from these statements.

RDFBean annotations

The annotations scheme has changed, so the old classes will be incompatible with RDFBeans 2.0. As you can see in the example above, @RDF annotation is now applied to the getter methods but not to the field declaration like in the previous versions.

You also can notice new annotation, @RDFNamespaces, which defines a list of URI prefixes to be used in other RDFBean annotations declared in a given class or interface. This includes class and property URIs, as well as RDFBean identifiers:

@RDFNamespaces({ 
	"foaf = http://xmlns.com/foaf/0.1/",
	"persons = http://example.com/persons/" 
})
@RDFBean("foaf:Person")
public interface IPerson {
 
	@RDFSubject(prefix = "persons:")
	String getId();
...

Annotations are now inherited from superclasses and interfaces that makes the RDFBeans markup compatible with complex domain-specific object models. See how the Thing, Agent and Person classes of the FOAF example are organized to mimic the owl:Thing → foaf:Agent → foaf:Person subclassing in RDF-Schema.

http://rdfbeans.sourceforge.net

About SCAN

“… the abundance of information will be such that either you have reached such a level of maturity that you are able to be your own filter, or you will desperately need a filter… some professional filter.”
Umberto Eco: A Conversation on Information
(an interview by Patrick Coppock, February, 1995)

SCAN is aiming for a solution of major problems of content organization and findability in information overload era.

SCAN aggregates content from different sources into a single documents collection. This repository may keep records on thousands of documents independently of their original locations and formats. Every document record contains a number of metadata properties (such as title, description, author, creation date, etc) which can be either set automatically or edited manually.

Adding documents to the repository is an automated operation. A user only need to point SCAN to a location and the application will find and add every document from there. Added document locations will be monitored for changes (new, modified or deleted documents) to keep the repository up-to-date.

The documents content is indexed for search and text analysis. You can search the documents either by simple text queries, or by using special forms to make complex queries for searching on document text and properties. The queries can be saved for repeatable use.

The documents collection is structured with a system of tags, similar to the services like del.icio.us or Flickr. Tags are keywords or labels attached to the items to identify them for quick navigation and finding. All tags together form a taxonomy representing the semantics of the documents collection. The taxonomy can be viewed as a “tags cloud” for navigating through the documents repository.

SCAN text analysis mechanism simplifies the process of tagging. It analyzes a document content and suggests the most relevant words as to-be tags. It makes manual tagging as simple as selecting the tags from the proposed candidates. It also can undertake the whole manual process of tagging, either by automated assigning the tags to the documents, or by finding the documents, relevant to a specific tag. Another text analysis application is searching the documents similar to a specific one (search by pattern).

SCAN is a component-based software using a number of plugins for specific features. The basic SCAN platform can be easily extended with plugins for new document formats, document locations (RSS feeds, web-sites, e-mail, etc) and language analyzers. Whole new areas of functionality can be added with user interface extensions. An example of such extensions is the plugin to browse the repository with a calendar (grouping the documents by their creation dates).

SCAN is a Java application, so it works on any Java-enabled platform. SCAN is a free open source software, distributed under Apache License, Version 2.0

See also:

• List of current features
• Download SCAN
• How to obtain SCAN sources from SVN repository
• User’s Manual

This decision seems to be related with recent turn of portal orientation towards a community-oriented service. As SourceKibitzer’s CEO Mark Koffman told me, “we are moving from software towards the people behind it”. Recently, the portal has launched new features to support this direction, namely online resume for Open Source community members (Bio) and series of interviews with OSS developers.

I think, it has good chances to grow into a real social network for the FOSS folk.

At the moment, the portal code is published under GPL v3 Draft. An exception is the proprietary libraries implementing the benchmarking algos, which are know-how of the company running SourceKibitzer. The portal invites everyone to join the development by subscribing the mailing list , participation in TRAC Wiki and contributing the code into SVN repository. The portal technology is based on Java Spring framework.

What is SourceKibitzer

SourceKibitzer is an online service for automated (so, unbiased) assessment, analysis and benchmarking of Java source code. For the moment, over 500 open source Java projects are analyzed (including, e.g. the whole Jakarta pool) and Kibitzers plan to “Measure all available Open Source projects written in Java”. SourceKibitzer works directly with CVS and SVN repositories to monitor the code development, so the reports are always in actual state.

SourceKibitzer methodology contains a number of various metrics and many of them are really useful and interesting.

Progress analysis
It is similar to Sourceforge “project activity” info, but on more detailed level. Kibitzer’s report contains progress information for each compilation unit (a package or even a single source file) – how many statements, methods and comments were changed during the last week.

Size analysis
Gives the total numbers of lines, statements, methods and comments in each package and source file.

Complexity analysis
It evaluates code complexity by measuring different metrics: the number of instaniations of classes (“Data Abstraction Coupling”), the number of classes given source file relies on (“Fan Out Complexity”), the number of possible execution paths through the methods (“NPath Complexity”), McCabe’s cyclomatic complexity of the methods and boolean expressions complexity.

Completeness analysis
It is based on assumption that number of conventional “todo labels” in the comments (“TODO”, “FIXME”, “XXX” etc) and total comments density mean the level of project’s maturity.

Kibitzer’s team say they are working on improving the methodology and plan to implement more metrics measurements in the future. You can submit your own Java project to kibitz it.

Sun believes deeply in creating communities and sharing innovations and technologies to foster more participation. Today in a historic move, Sun is opening the door to greater innovation by open sourcing key Java implementations—Java Platform Standard Edition (Java SE), Java Platform Micro Edition (Java ME), and Java Platform Enterprise Edition (Java EE)—under the GNU General Public License version 2 (GPLv2), the same license as GNU/Linux.

What parts of Java family had been released actually?

• A full buildable version of Java Platform Micro Edition (Java ME)
• A part of Java Standard Edition (Java SE), specifically javac, HotSpot and JavaHelp. Releasing of a full version (including libraries code) is scheduled “in the first half of 2007″.

Cafe au Lait thinks that “Part of the hold up is simply that Java 6 is not currently fully buildable with open source tools” and it seems it is very likely so. For good or for bad, software code is still closely tied with bulding and managing infrastructure and I can foresee all complexity of moving Java libraries on conventional open source framework. If the reasons is really in that, it forgives Sun and we should be thankful for they are taking care for we, users, would be able to, say, simply type “ant” to build the whole codebase.

Why GPL? A week ago I wrote that the question of a Java license seemed debatable inside the Sun staff. In my opinion, the final choice was made by two essential reasons. First, it is straightforward compatibility with GNU/Linux, which seems to be a general strategy of the company. Second, there was a lot of (reasonable) criticism that Sun makes a needless mess with invention of their own open source licenses (such as CDDL).

Open source Java is available as OpenJDK project on java.net.

After long period of indistinct reassurances and promises and, finally, the triumphant announce on open-sourcing Java SE platform before the end of this year, it is the first interview that sheds some light on the details of this topical question.

The people who concern both Java and OSS development were, of course glad to hear that hopeful news from Sun although there was a lot of questions, as legal as well as bare technical. In this interview, James answered to some of them.

Likely the most mind-blowing issue is a license of the future Java platform releases. James has emphasized its importance and even stated that “The difference between what we do now and open source has mostly been around the license”. Although, no of the specific license types had been mentioned. But without doubt, it will be a OSI-approved license and apparently, the same as of Solaris (CDDL, based on Mozilla Public License). It was declared by Sun CEO Jonathan Schwartz at his October’s “open-sourcing Java announce” (see above), but later Sun stated officially that “We’re not ready to talk about the licenses”. So I suppose, consensus on this question is still not reached in the company and James politely left it aside.

[Upd:] Earlier (after May’06 JavaOne), Jonathan wrote in his blog that “using a GPL license is very much *on* the table”, so the choice seems between GPL and CDDL. However, the results of the Java.net poll shows that the Java developers community also would like to see Sun’s JDK under Apache license (30% against 22% for GPL, 14% for LGPL and only 6.8% for CDDL).

The motivation of open sourcing Java is stated briefly and clearly:

We want better conversations with the developer community, a more collaborative relationship. We want to have better relationships with many of the Linux distributions…

I think, taking care of compatibility with Linux distros is remarkable and it confirms the fact that more and more of the leading corporations cannot ignore this platform anymore. Indeed, it is oddly enough that Sun is selling their machines with Ubuntu preinstalled, but Ubuntu developers cannot include Sun’s JDK into the distribution by licensing reasons. On the other hand, the results of heroic efforts on the alternative open-source implementations are still far from the “original” Java to be useful at any rate.

An important thing is how the project will be organized. It is looking like that the development model will be far from a “bazaar-style”. The process of defining the specifications will be kept by the Java Community Process (as it is now), that is general direction and major design decisions will be still somehow controlled by Sun.

So it shouldn’t give anybody any concerns as far as fragmentation. We’re not just going to let random people check random code in. Just like every other open-source project, we will end up with a set of rules for who’s allowed to check in a lot. Everything will get checked and rechecked and debugged.

It is noteworthy also that the project will use Mercurial for source-code management, instead of conventional CVS which was said “don’t work well for large-scale projects”.

Indeed, not too much of info but it’s looking like nobody in Sun doesn’t know more at this moment. The web-page of Open-Source Java Initiative now contains only the list of persons behind it.

[Upd:] I’ve found that the home of open-source JDK community is actually here.

II. Technology

Version Control

Open source development without networked version control system is like a running on crutches. It is not enough to publish your sources on FTP or web-server for free download. Very soon you’ll start to receive the patches and bugfixes and will face with lack of resources to manage them and maintain the product. So, an idea to have a shared sourcecode repository and to allow active contributors to apply their changes themselves is obvious.

Using the Concurrent Versions System (CVS) or Subversion is a common practice for collaborative opensource development. There is no matter how large or small is your community or a code base. Learn it. Use it. It is a necessary condition of successfull teamwork.

A knowledge and a lot of helpful tips on using CVS for opensource projects can be obtained from Bar&Fogel book [2].

Project workplace

There are free internet services which provide hosting of opensource projects and an infrastructure for collaborative development. As user of that service, you are supplied with a solid workplace for your team and got rid of many infrastructural aspects of project maintaining. If you’re in doubt where to go, register the project on the SourceForge.net — a popular and mature workplace for opensource development which provides almost everything you need for your project, including:

• CVS repository
• Hosting of the public web-site
• Mailing lists and web forums
• Public bugs, patches and feature requests tracking system
• Time-tracking and task scheduling tools for development planning
• File releasing system with a number of mirrors around the world
• Tools for advertising your project and recruiting new members

The only problem with SourceForge (although, it is common for today’s internet) is a namespace issue. It is rather hard to register new project with a sensible word as its name there…

Web-site

Web-site is a public facade of the project and a powerful tool for supporting the users, recruiting new members and project advertising. Run and support it from a very initial stage of your project. The web-site of the open-source project typically contains the following information:

• Project news, including the announcements of new releases.
• Project overview — a brief introduction into the software, project and its mission.
• Documentation: User’s Guide, HOWTO and FAQ, articles, developers documentation etc.
• Download page, including a guide on how to download, build and install the software
• Development overview (or “Get Involved” page) — describes the development process, including information on how to join the project for new contributors, as well as how to report bugs, submit patches etc.
• Contributors list
• “Contact us” page, including email adresses of project coordinators, mailing lists subscription etc.

Keep the web-site content in an actual state. It is a good idea to put content in CVS for collaborative updating.

Mailing lists

The mailing lists are conventional tools for communication among the project’s community and users. Typically, an opensource project runs the following types of lists:

• Developers mailing list — a main discussion forum of the community.
• Users mailing list is for discussions among end-users and developers. It is where users can get help either from developers or from other users.
• Announce mailing list is a sort of newsletter for the people who want to be notified on new software releases.
• CVS automated mailing list is helpful for CVS users who want to be notified about every change in the code repository.

Public bug trackers

Encourage users to report the bugs using a special bug-tracking service on the project’s web-site. It allows your team to keep a consistent bugs database and fix them faster.

Read more on bug tracking at Joel On Software: Painless Bug Tracking.

It is also a good idea to use the tracking tools for new feature requests and software patches submissions.

Downloadable file releases

Make new release every time when a noticeable bunch of new features or bugfixes is done (an opensource everyday wisdom is “Release early, release often”). It may seems unnecessary if the project provides an anonymous CVS read access, but the most of end-users don’t use CVS and prefer to download the file releases. It is also a reason for good practice of making the “nightly CVS tarballs” — the downloadable archived copies of the whole repository built automatically at every night.

Besides the sourcecode release, provide a prebuilt binary version— for those users, who cannot or don’t want to compile it on their own side.

Automated building

Don’t make other developers and users to install your favourite development tools to build the sourcecode. Use conventional automated build systems — such as Ant for Java projects or make for C/C++. Building the sources should be simple as possible. In an ideal case, an user should only run the build script to get the software compiled and ready to start.

It is a good practice to use a build script as a central point for complete code management — not only for compilation, but also for product installation, building a documentation, tests running, making the releases, launching CVS functions etc.

Automated testing

A practice of the “test-driven development” with automated testing frameworks such as JUnit, saves a lot of time for debugging and provides more reliable and bugs-free code in comparison with manual testing. Write test cases for everything and run them so often as possible to be sure that the code is workable. Encourage other developers to write test cases for their new features.

This is especially important for teamwork, because the situations when someone accidentally breaks other’s code are not unusual. Providing the “quality requirements” in a form of test cases and suites smoothes the problem. When developers are used to run the test suite before each CVS commit, the code in the repository will never be broken and be always kept in a workable state.

Good software design and usable code

Good software design increases the developers productivity. If you think these are buzzwords of commercial software industry, you’re wrong. As it was said above, the time of developers work is a most valuable capital of an opensource project and don’t let it be spent for long investigating and learning an existing code. Every programmer knows how difficult the exploring of another’s code might be, so produce an evident design and usable code from very initial stage of the product. Your initial code is a foundation for all subsequent add-ons and if it is well-designed, it will encourage other developers to keep and follow that design as well. The developers are enjoyed by a well-designed code and it motivates them to work with it, while the intricate, hard, obfuscating code makes them tired and they leave the project.

Use conventional object-oriented design techniques with thought-out classes hierarchy, concern separation and effective modularization. Provide a consistent and documented software API as a basis of the whole application. Think over the consistent and understandable identifiers scheme and comment the code where possible. It will save a lot of developers (and yours) work hours in future.

Design patterns

Design patterns are succesfull solutions which can be repeatedly used in various applications. In object-oriented design they are predefined organizations of classes and relations among them, such as well-known Factories, Iterators etc. The comprehensive guide on using the patterns in OO design, including their taxonomy and classification is given in the “ Design Patterns: Elements of Reusable Object-Oriented Software” classical book by Erich Gamma et al.[3]

Usage of patterns improves a software design and understandability of the source code. It also provides a common vocabulary for developers discussions, so you always can say: “I gonna implement a Facade pattern there”, instead of long explanations of what do you want to do.

A component technology

Think about your program as it is a framework for random features of specific problem domain, rather than a specific fixed set of features. The component-oriented programming techniques benefit not only for good software design and product flexibility, but also for community. When specific pieces of functionality are designed as the separate modules (or, “plug-ins”), the development process can be splitted into few independent lines with their own developers and maintainers. So, new developer who interested in specific feature can quickly start to work around it without diving into the whole code base. It makes adding new features simple and your community will not spend a time for flaming about where to go and what set of features a software should contain. When someone falls in opposition with her idea of a new feature, she can develop it as a plug-in and let users decide themselves on using it.

Avoid to reinvent the wheels

Learn about common standards, practicalities and third-party solutions which can be used in your software. They will save a lot of time for you and your community. For instance, if your program needs for a structured data format, use XML instead of your newly invented one. Before going to implement some feature which doesn’t seem unique for your area, try to look for appropriate third-party solution. The development process will go faster and new developers probably will be already experienced in that technology, so they will be able to start a “real work” immediately.

Using well-known and conventional technologies increases the speed of development, because it increases an amount of the “shared knowledge” in community.

Documentation

An another way to improve the “community knowledge” is to document everything whenever possible. I mean not only the user manuals and help, but also technical documentation written by developers for developers.

The tools like wiki make a great help for this.

Internationalization

Your software will be used around the planet by people speaking various languages. Although the English is a conventional language of opensource culture, the people prefer to use localized software in their countries. Don’t use hardcoded labels, messages and other locale-sensitive data in the program, but provide flexible localization framework enabling easy replacing default values with their local equivalents.

National localization is also a good way to attract new project members (see the “Motivate users to contribute” section). By my own experience, many of active developers started from contributing the localization packages for their native languages.

Accept donations

Some people or organizations would like to support your project with money or other resources. This is good and you should not reject such kind of contribution — after all, this is equivalent of that other people contribute their labour. Leaving aside the time and efforts you invest into the project (assuming you compensate it with fun and satisfaction of your own technology needs), you usually bear direct costs on hardware equipment, internet connection, domain name support and so on. So, money donations are undoubtlessly helpful for the project.

… and have fun

This is a final recommendation, that I’d like to tell. Be enjoyed of your project and let the people be enjoyed of it. Don’t let it become a boring thing. Boredom is the main enemy of an opensource.

Happy coding!

Bibliography

1. Raymond, Eric Steven. “The Cathedral and the Bazaar”. 1999, O’Reilly, Sebastopol, CA.
2. Bar, Moshe and Karl Fogel. “Open Source Development with CVS”, 3rd Edition. 2003, Paraglyph Press, ScottsDale, AZ.
3. Gamma, Erich, Richard Helm, Ralph Johnson, John Vlissides. “Design Patterns: Elements of Reusable Object-Oriented Software”. 1995, Addison-Wesley Longman, Reading, MA.

Well, you’ve developed a useful piece of software for your own needs and you want to share it with the world. Or, you have a great idea and going to implement it in a collaboration with other interested parties. Or, to be more prosaic, you did an initial software implementation, but realize that you have no resources to push it through to a productional quality stage. Anyhow, the best what can you do is to start an open source project.

Above all, have no doubts — you’re on the right way in any case. Your home-made software will be recognized by the whole world. You will see how your brilliant ideas are evolved and implemented into the new technologies and software applications. And you will get high-quality software for your needs without hiring a team of high-paid professional developers, managers and beta-testers. You will get a lot of new friends around the world, an experience in software design and development, a fame and reputation (and maybe a money, why not?). In addition, sharing your ideas and software code brings a great moral satisfaction and it is a good practice to improve your karma.

Starting and initial arranging the project is easy and with free hosting services, like at SourceForge, you don’t need anything except for few hours of your time. It is much harder to have success with that project.

Obviously, your software should do something useful for other people, but it is ultimately not enough for the project success. Your efforts on developing an initial code is only a start point of your path and there are numerous traps and rocks on your way. It wouldn’t be so, if only there were no interesting and promising free software projects which were unfortunately failed because of some flaws in the process itself.

This article contains my observations about how to get a successful opensource project. This is a summarization of my own experience on starting, leading and participating the free software projects (including my mistakes and failures) and of analysis of succesful opensource software. Also, the content of this article had a strong impact of explorations on social aspects of the opensource phenomenon made by Eric Raymond (read his classical essay “The Cathedral and the Bazaar” [1] and other articles to be up on the question) and Moshe Bar & Karl Fogel — authors of the “Open Source Development with CVS” book [2], which is not only a CVS guide, but also a great source of helpful ideas on opensource development process.

What is a succesfull project?

You can say a project is succesful for you if it matches your personal goals and expectations. Right, but this is only effect of success – it is your profit. The criteria of success is mainly the same as for any (commercial) software: the project has a high-quality and popular product.

I. Community

Commercial software needs for investments – and open source too. But this is not money investments – this is labour and time of the project contributors. When someone develops a software design, does coding, testing or documenting, he or she invests her labour into the project. So, the project should be attractive for investments and continuously obtain this kind of funds.

The only vital condition of open source software success is community.

Linux is so successful not only due to the brilliant ideas and their implementation, but to effective development model attracted a high-quality labour of a lot of skilled Unix hackers worldwide. Linus’ initial code was a great thing, but it would never be the today’s Linux system if there were no collaborative efforts of many people around the world. A reliable and productive community of highly interested and enthusiastic volunteers is a main capital of an opensource project and the key factor of its success.

That’s the point — to run a succesfull project it is not enough to be a talented coder and software designer. Since you’ve released the project, you have to get some, probably new skills — such as marketing, PR and even poitics. You should learn for collaboration, effective team management and ability to inspire the people.

Be straight in your intentions

Don’t be untrue. You’ll get other people joined in a project only if they’re sure they contribute into a real free software. You can do your best to straightly declare a free nature of the sourcecode if you’ll put it under an opensource software license.

Provide true information about you and your goals in the project. Don’t conceal himself behind a nickname — this is a habit of stupid crackers and may arose suspicion. You do a fair job and your real name worths a respect and fame.

Choose an appropriate opensource license

Depending on your goals, you can choose one of the opensource licenses:

• The GNU General Public License (GPL). It constraint anyone from making proprietary closed-source product derived from GPL-licensed software. Use GPL when doubt.
• The Lesser GNU General Public License (LGPL). The variant of GPL created specially for software libraries. It allows to use LGPL-licensed libraries in proprietary products (the GPL itself does not permit to do so).
• “BSD-like” licenses, such as BSD (Berkeley Software Distribution) License, or The Apache Software License. The licenses of this kind doesn’t prevent to make proprietary products based on your code. They have relatively few constraints — mainly, concerning required mentioning a copyright of original author in derived products (proprietary or free) and prohibited usage of the original software name.
• The Artistic License. The GPL-compatible license adapted by PERL community.
• The Mozilla Public License (MozPL). It discourages of making proprietary derived versions, but allows to create proprietary add-ons.

These are the most popular licenses which are fit in 99% cases. The Open Source Initiative provides full list of licenses approved to be open source.

Of course, you can invent your own software license, but in this case new users and developers will be forced to spend their time for examine its terms and you’ll, perhaps, be asked for a lot of questions. So, do not complicate the things and choose one of the well-known OSS licenses.

Publicize your project

If you think opensource software doesn’t need advertising, you are quite wrong. Don’t be diffident and stingy on advertise your project. The more people will learn about the project, the more chances you get to enlarge your community. Announce it in the blogs, mailing lists, forums, newsgroups and among other network communities. A direct mass mail to people involved in the same area may have a good effect also. Maybe, you’ll get a few replies blaming you for spam, but if you’ve selected the right target audience, the most of the people will be happy to learn that something new is appeared in their area of interest.

Motivate users to contribute

The users of your software is a primary source for recruiting new project members. There already is a kind of the “power users” who enjoy to play with a program, hack it, customize it and try to improve it. They are the best candidates for new developers.

Let a software to be attractive for improvements. It is not that you should make it intentionally buggy and ugly (though, every initial release is buggy and ugly anyway), but it should encourage users to make it better from point of view of their experience and preferences. National localization, user interface skins, pluggable features, scripting and other sugar are effective attractions to explore the software from a backside and start to contribute.

Cultivate your community

Encourage people to contibute into the project. In fact, working in a friendly collaborative environment is one of the powerful motivation to contribute for many people. Keep this athmosphere of good will, collaboration and common understanding and your community will only grow.

Don’t let the people feel they do something personally for you – this is ultimately not the case since you’ve published your code. Let them feel this is their project as well as it is yours — and this is really so. Don’t turn your authority as an initial developer and project maintainer into dictation. Remember Tao: “If you want to lead other people, you must put their interest ahead of your own”.

Respect other’s opinion and try to answer personally for every feedback. Above all, pay your attention for constructive, argued, technically proved suggestions with designated ways of solution. Follow the same style in your own postings. Put important decisions concerning the whole project to discussion and voting. Besides of the well-known fact that the collective brain-storming brings the better solutions (the “Delphi effect” [1]), this is also an opportunity for everybody to feel a value of her personal opinion.

Don’t ask the people to contribute and don’t make them feel any responsibility for it. For a lot of people it is just a fun and you have to value this attitude, because fun is a great driving force. In fact, a big deal of outstanding serious software has been made for fun. For many developers the project is an opportunity to do their favourite job without deadlines and bored managers. Such spirit of fun, freedom, ease and enthusiasm is the best athmospere for opensource communities. Do your best to keep this spirit, cultivate it and be actively involved in it.

Don’t hurry the people. If you granted a commit privileges, don’t expect for continious active contributions and don’t rob the access privileges back even if a commiter is inactive for a long time. Instead, try to inspire the people by your own enthusiasm. It is experienced that the project activity grows (and falls) exponentially — the more people are involved in active development, the more people get motivated to be involved too. It may sounds like a paradox, but lack of deadlines actually doesn’t slow the development process. In fact, many opensource software is developed faster than their proprietary competitors, although the most part of developers doing it in their spare time. I think, the reasons of such phenomenal productivity are ?pen nature, freedom and enthusiastic spirit inside the team – the things which are hardly reachable in the corporations. As far as I know the programmers, they are very hardworking and sedulous people, and the opensource is an ideal environment for exposing these habits.

When once you feel your project lives by its own life and is no longer depended on your personal will and efforts, this is a great milestone. If you were away for month or two, then got back and discovered that there are new version releases and project members, be sure you’ve reached your goal to create a succesfull project community.

Cultivate project reputation

Cultivating a community is not that you should please for everybody and turn the project into a public amusement. After all, the goal of the project is to develop a software, but not to have fun in a community. The project have to have the certain direction and the project maintainer is responsible to keep it on track. Be able to say no when it is needed. Use your authority for judgement and rejecting the features which are definitely out of subject but always provide a reasonable argumentation and be polite. If you’re in doubt, put the question to public discussion.

Before granting a commit access to the repository, imagine yourself as an employer hiring new workers. The internet users are just the reflection of human society and don’t be surprised if you meet not only intelligent and skilled developers. There very well may be the people from a well-known and ubiquitous tribe of “enthusiastic fools” who can smash the whole code base by very kind motivations. Despite all their demolitions are easily recovered with versions control, it is better to recognize such people on very early stage of their activity (fortunately, it is easy) and keep them at a safe distance of the repository. Also, be suspicious for anybody who doesn’t reveal his real name and email address. Grant commit access for well-known community members who have already been proven as the authors of helpful contributions. It is not that somebody is able to make an irreparable harm to the product or to the project infrastructure (as it was said, it is all recoverable), but hurting the project reputation is much more important thing.

Cultivate project leaders

You cannot guarantee you will maintain and coordinate the development during all the project lifetime. You may get uninterested and get busy on something new, or one day you’d realize you did all your best for this project. Actually, many opensource projects are led by the followers of initial developers.

When your project have a stable and reasonably large community, invite few responsible and active commiters and ask him to share your project’s admin privileges. You will make your own maintainer’s life easier and should be guaranteed the project coordination will be in reliable hands when you’re gone.

Part II. Technology >>

Memoranda

I began to think about changing jNotes name as far back as I started to work at Version 2. It seemed to be basically new product, rather than just new version of jNotes. Another reason was annoying confusion with another software called JNotes – some Java stuff related with Lotus Notes. So, I posted my thoughts to the mailing list and asked people to suggest new names.

Ten variants of new name were proposed:

• InteliNotes
• Notestopia
• Memoranda
• LineUp
• Jot
• NoteSoup
• MyNotes
• NoteBurn
• Jilofax
• Chronicles (my variant)
• … oh no, “jNotes” forever! (another my variant)

As a result of voting, the “Memoranda” name invented by Iván Ribas was selected. I very liked that name and voted for it too. At the end of September 2003 we registered new project on SourceForge, moved the codebase and made new release under new name. New web-site had been launched at the same time. The old site was remained as a home of jNotes 1.0 (currently inactive).

Since then, among increasing stability, the software got a lot of new features. The most important ones are:

• Summary page (“Agenda”)
  A “today startup page” which summarize information of active tasks of all projects and upcoming events of this day.
• Hierarchical tasks
  Now the tasks of a project have hierarchical structure, so that every task may contain sub-tasks.
• Multiple notes per day
  until recently, a single calendar date was associated with a single note. Now it is possible to have few notes associated with the same date.
• 14 national localizations
  Now Memoranda speaks Catalan, Chinese, Chinese (Taiwan), Dutch (Belgium), Dutch (Netherlands), Finnish, France, German, Hungarian, Italian, Japan, Russian, Serbian and Spain. The language of GUI is selected automatically depending on user’s system locale settings.

The current status of Memoranda is 1.0 Release Candidate 2. The next release (I hope) will be final.

Memoranda 1.0-RC2 screenshot

Who did it

Many people in different time took part in Memoranda development. Above all, these are code commiters:

• Patrick Bielen (pbielen)
• Ryan Ho (rawsushi)
• Yunjie Liu (noregister)
• Iván Ribas (ivanrise)
• Carel-J Rischmuller (carel-j)
• Jeremy Whitlock (jcscoobyrs)
• Jyrki Velhonoja (velhonoja)

And those who were not the developers, though they did the great help for the project:

• Thomas Chuffart
• Willy Dobe
• David Nagy
• Kenneth J. Pouncey
• Sava Rados
• Michael Radtke
• Milena Vitali-Charewicz
• Toru Watanabe
• … and everyone I may have forgotten, sorry.

(all people listed alphabetically by their second names)

I don’t say thanks because this is our software, not my own ;-)

Memoranda 2.0 ?

My thoughts on Memoranda future are coming soon, so the saga continues…