Frequently Asked Questions

Owned by NiclasH
Last updated: Jan 24, 2007Version comment
4 min read

What is wrong with Open Source projects?

There are essentially three types of Open Source projects in the world;

  1. Merit based.
  2. Privately owned.
  3. Commercially controlled.
Merit based

In the first category you find projects like the one at Apache Software Foundation, CodeHaus and the Linux kernel project. They are based on a principle of inclusive by merit. That means that you need to prove yourself worthyto be part of the committer community. You will need to spend time working on the project, submit patches that you think will improve the product, be part of discussions around the development, but without any formal say. Once included you can lay back, and take credit for being part of the project. You have earned your merits, you are someone.

We find this counter-intuitive. In some projects, the real hard work of tracing down obscure bugs are performed by outsiders, yet the peopleinsidetakes the credit for the project's success. Some individuals will leverage their association with such project, and in some cases the people on the inside are blocking progress, as is their right in some meritocratic projects.

Privately owned

SourceForge is probably the largest holder of privately operated open source projects. They are started by a single individual, and he/she alone decides who else gets access to the codebase. The code administrator can also promote other committers to administration rights, at which point this category starts becoming a merit based one.

Since this category has no common traits, other than the single originator, it is hard to criticize at a general level. One can however notice that it is initially very difficult for the admin to attract a following, sometimes due to the exclusion by default principle that is inherent at SourceForge.

Commercially owned

Projects like MySQL, NetBeans and Sleepycats BDB are Open Source projects developed for commercial purposes. The main purpose is to drive business, based on the concept that people are less afraid of using Open Source projects than commercial products, as the entry-level is cheap and in case of any problems, oneself can theoretically find the bugs.

Of course, we don't really like this, since we can't participate at all. Any contribution is most of the time Copyright assigned back to the original contributor, and you are essentially nothing more than a user to the project, no matter how much you contribute.

Why does "No Barrier" projects make sense?

Almost always (see below). If people take the time to get themselves registered, and digging into the intricate details of suggesting changes either in form of debate or patches, they have shown that they are capable and committed. It is important for a project to have mechanisms in place to easily revert any malicious changes, and once the cost of restoration is lower than the cost of destruction, the evil-doer is bound to go away. Wiki works on these principles and apparently works very well at for instance Wikipedia.

When does a "No Barrier" project not make any sense?

High-profile projects, where there are strong forces interested in disrupting its progress. Examples; Apache Httpd, JBoss core and Linux kernel. We believe that very few of the thousands of Open Source projects out there falls into such category.

How does it work here at OPS4J?

Who is in control at OPS4J?

The answer should be; Everyone. But that is not entirely true. OPS4J is still in a start-upperiod, and The Executive is charged by the founders to establish a working solution for the required restrictions, such as root access to machines.

As a user, what licensing applies to me?

The intent is that each individual who owns the Copyright of something, grants a Apache License for all users. Any project must carry the licenses in the distributable, and all source files must have the license reference at the top of the file (if possible). If you find any discrepency in this policy, please notify us on the general@lists.ops4j.org mailing list.

What can I do to make OPS4J better?

Participate! OPS4J is all about participation, and that means that you chip in a hand in any way you want. Write articles on the Wiki, start new interesting coding projects, discuss anything related to Java on the mailing list, help write javadocs for existing code and evangelize the concept , that we call Open Participation Software to friends and associates. You can of course, donate other resources as well, such as software licenses for commercial products, hosting services and engage people here as consultants to work on your Open Source ideas.

I want to start sharing some code and invite others to help out. How do I do that?

The path is to start in the laboratory. It is the place where ideas are tested and code maturing into something useful. You find the laboratory in the Subversion repository at https://scm.ops4j.org/repos/ops4j/laboratory/users. In there, create a directory typically with your name, and just fill it up with your stuff. It is expected that any material is Apache Licensed (ver 2).

If the project attracts some crowd and interest from users, and that you want to start the road towards a first final 1.0 release, you should move the stuff over to the /repos/ops4j/projects directory. A short discussion on the general@lists.ops4j.org mailing list should take place before this step happens.

And by registering yourself at the Jira system, http://issues.ops4j.org/ you automatically have commit rights to most part of the code repository.

I have found a bug in some code, what shall I do now?

First of all, don't waste time to produce a diff. Noone will apply it. Instead bring the issue to the mailing list general@lists.ops4j.org to discuss it. There are of course cases when discussion is not needed, such as typing mistakes, missing javadocs and lots of other. If it is a significant bug, it makes sense to raise an issue in Jira, on http://issues.ops4j.org. When you register on the Jira system, you will automatically receive commit rights to the code repositories. You can then proceed to apply the changes. Notifications of the changes will be sent to notify@lists.ops4j.org, and others will review, make additions and possibly revert it if there are problems with the changes made. A discussion will typically arise on general@lists.ops4j.org as a result.