8

I'm currently the sole maintainer of an API that a friend and I have written. It is currently written in Java, and is designed to make a lot of the low level interfaces high-level, to help ease the learning process of beginners learning Java. It's sole application is in my school, where other students who have never programmed before use it, to use in basic projects. For example:

import arctic.lights.dev.FileIO;

public class getLettersInFile 
{
    String[] fileLines = FileIO.getAllLinesInFile("path/to/file.txt");
}

It's well documented, but we're looking to seriously expand it, and make it available to other beginner developers and schools.

Currently, since it's not very active, and is only used within our school, updating and maintaining the project is easy, and not very troublesome. However, since we are expanding it, and making it available to other schools.

With the school year coming up, my friend and I are becoming increasingly nervous about expanding, and the lack of available time to successfully maintain the project. Currently, the project is not publicly available, but we're looking to hosting it and getting a license for it. If we do make it available, our main concern is creating a backlog of requests and issues among places. With courses that start in September, we're predicting that the biggest spike in activity is going to be at that time, especially if bugs are found. Pull requests likely won't be very popular - the end users of the API don't really know much about programming...

My friend and I have a couple questions:

  • Should we be looking for an extra maintainer to alleviate a predicted backlog? As students, is it appropriate to be looking for an extra maintainer?
  • If we do end up looking for an extra maintainer, what should we be looking for in a potential maintainer? This maintainer won't likely come from our school (my friend and I are the most competent developers known), so we want to make sure that we find someone that won't try to "take over" the project, as it's also a learning experience for us.
8
  • 2
    Sounds like you are stressing over imagined problems (or have not explained clearly). If a PR is bad you don't merge it. Not merging PRs represents zero work on your part. Having a large backlog of PRs is not in and of itself a bad thing. I'm not seeing why you need an extra maintainer. Sep 3, 2015 at 1:11
  • @congusbongus Our issue is that we're going to be getting feature-requests, and issues, but no pull requests - due to the nature of the audience. Our concern is that we're going to get a backlog, and possibly a bit of complaining. It really is just my friend and I working on the project, and we didn't want to be stressed over it with the school year coming up. And yes, they are predicted issues.
    – Zizouz212
    Sep 3, 2015 at 1:15
  • 2
    If you do host this, and/or if you do decide you want another maintainer, send me a link :)
    – ArtOfCode
    Sep 3, 2015 at 6:58
  • 1
    You've gotten some very good answers, but I've something to add that isn't really directed at your question. Do you want to be responsible for maintaining this project forever? It doesn't sound like you do. If you don't want to maintain it, then don't. Trust me, FLOSS is great, but it's also a terrible time sink. You may find yourself feeling responsible for the product with no motivation (beyond that responsibility) to actually maintain it. You can either not release it at all, or release it with a disclaimer that it's not under active development, but PR's will be considered.
    – RubberDuck
    Sep 4, 2015 at 0:35
  • 1
    There are at least two types of people interested in students learning to program well -- the student and the teacher. If somebody at another school teaching Java 101 sees this and recommends/requires that students use it, you probably will have somebody submitting pull requests, as they will want to improve the library for their own classes. I would also not be surprised if the only way the project becomes popular is to get teachers on board; you'll want documentation to show how the library helps students learn without becoming a crutch.
    – Ryan Frame
    Sep 7, 2015 at 12:15

3 Answers 3

4

First of all, you're worrying about an assumed problem. You two may run out of time, get a backlog of issues ... or not. So it might not even happen that you run into problems.

You also may simply do no maintaining at all. Nobody is forcing you or your friend. Or you could do as much as you can manage. Some people might complain if their issue isn't resolved, but in no way you can be forced to act upon it. Some open source is released without giving users a feedback-channel at all (that was more common in the past, now with internet feedback is more easy to achieve and more accepted). A possible user for such unmaintained software can use the software as it is, (s)he can leave it be if the issues are too big for you or (s)he could change the software according to own needs (the last option is possible because the software is open-source, a great thing).

For your software in question you two could decide to always adapt the software for the needs of your own school, but ignore external requests. Again some external user has the above mentioned options.

Or you two could do as much maintaining, as you can and want. Nobody can force you for more. In this case it may be helpful to communicate that you can only afford so much time for maintaining. Make a note on the website and pick issues you want to work on and issues you not want to work on and communicate that.

In my experience many projects don't get much attention, especially at first. It may depend on the channels though, in which it is advertised. Simply putting it on github doesn't create much attention, so you get not much users (and not too much maintenance work). In your case teachers in computer science might tell teachers of other schools about the project and create attention this way. Maybe you want to control growth of the project and involve at first only a few other schools, so that the maintenance effort is manageable. After that involve even more schools and so on.

3

As a maintainer of a project, it is your responsibility that the project functions as well as possible.

Noticing that you lack the time to do everything you want to be done is a very good start. Then it's time to act on it. Some projects work very well with a single maintainer. Some people work a lot better when they are a single maintainer. But that doesn't go for everybody. It is perfectly alright to have multiple maintainers, if thats how they prefer to work.

Now for your situation, it's a bit tricky because this is not a collaborative open source project yet, you are only considering to make it one, and you don't have experience in maintaining an open source project yet, so you don't really know where your strengths and weaknesses lie yet, nor do you know how to work in a collaborative project yet.

If you know you'll have too little time to be a good sole maintainer though, getting more maintainers aboard is a great idea.

Be careful though, because it's easier said than done. If you don't expect people to submit pull requests, where do you plan to find your maintainer? Usually those things grow organically from people who are active in support and writing code, and get at some point commit access. You are going to try and pull one from thin air, and thin air is not known for its high concentration of high-quality maintainers.

So yes, by all means, if a suitable candidate stands up, make them a co-maintainer. But beware that it might be tricky to have a suitable candidate stand up.

As a practical note, things that may help you are

  • Letting the community know that you may not respond timely
  • Encouraging community reviews of pull requests

You could always contact someone who reviewed well if they are interested in becoming a co-maintainer.

1
  • Do what you need to do to keep the project running smoothly.

    If you predict heavily increased usage over a certain period, and you don't have capacity to deal with it, then what you need to do is get another developer on board.

    Is it appropriate? It's your project, you can do as you like with it. Is it appropriate to be developing this API for your school? Only you can answer that one.

  • If you do want an extra maintainer...

    Two important attributes of anyone you take on:

    • Decent developer
    • Team worker

    You don't want someone who tries to take over the project because he thinks he's a better developer, nor someone who'll hold it back through not having enough skill. Choose wisely. You might be able to just admit pull requests, and choose a collaborator based on those. Alternatively, pick a volunteer you know :)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.