Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I'm working on an application and I needed an API wrapper for it. I noticed that most of the API calls I needed weren't implemented, so I went ahead with adding them in. There are a few bugs that need fixing which I'm planning to fix as well.
My problem is that development of the wrapper is almost non-existant at the moment. A bug submitted with a patch from October 2009 has been ignored so far.
I've emailed the main developer so I can commit my changes or even submit them somewhere, since on the homepage, it said that he's the person to contact with this sort of stuff. I've also asked about this on the discussion board, with no response.
My question is, how long should I wait for a response before forking this wrapper? It's one of only two open source wrappers for this API and listed on the API Doc's page. I hate to see that there's no improvements to it.
So, how long should I wait. What's normal for this kind of thing?
In case it matters: the licence is Simplified BSD
UPDATE:
The original developer finally responded; so I didn't end up forking. Apparently he was just very busy with work.
A good (relevant) article to read for anyone coming across this question: http://dashes.com/anil/2010/09/forking-is-a-feature.html
And thanks to everyone for your answers!
You can fork any time you want. Once I was in similar situation. As I had informed project admin that I'm going to fork, I obtained a response and it wasn't necessary :P
BTW I have written to sourceforge crew (project was hosted on sf) and that was their advice to fork.
Perhaps I am a little late but would like to answer on the level of definition.
The term Forking (branching away) refers to a split between groups and development in different directions. In this case a branching away can not clearly be seen so there was not actually a forking of a product. The action was clearly an alteration (extension) for a personal need. Should a product experience alterations and the result again be returned to the group it comes from is forking also not the proper definition. By definition open source encourages you to alter.
It depends if you plan to maintain your fork. If you do then the chances are it will become a better project than the original. Otherwise maybe wait a couple of weeks. Still, even if you released today there's nothing to stop the original project merging your changes so the community as a whole benefits either way.
There's no protocol, just call your fork something else and give the original prosjekt plenty of kudos for the original work.
Forks happen all the time, it's not necessarily a 'divorce' with the origial maintainers ... just happy coding.
Your additional calls might be usefull for someone else, but then again it might not.
Does the project has a publicly known mailing list/bug tracker, and if is - is it affordable to submit a patch there? Also, can't be a developer - become a maintainer at one of popular Linux distros, (submit a Gentoo bug/Launchpad entry).
If there's no sense in such actions - just fork.
Sounds like you've done the right thing though and tried to stay within the existing branch and now it is appropriate to fork.
If nothing else, forking is a more powerful action than most other things i.e. if you fork and still don't get the original developer's attention then you can be satisfied that you did the right thing. Of course once forked, there's no real reason why there can't be some convergence at a later stage.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I've been holding off on releasing a library I wrote because it is the first library which I'll be releasing publicly. Here are my concerns:
The library isn't complete it is in a very usable state, I'd say it is version 0.3, however it still lacks a number of features which I would like to at some point implement, and control how they're implemented (meaning not merging someones implementation).
I'm fearful of criticism, I know there are a few things which should be reorganized/refactored, but I wrote the initial class quickly to be functional for another project I am working on.
So when is the best time to release? Should I just throw it up on github and work on the issues post-release? Or should I wait until I refactor and feel completely comfortable with what I have written?
Most classes/libraries I see are always very elegantly written, however I have not seen any in very early release stages, are a lot of classes fairly sloppy upon initial release?
Release early, release often.
Criticism is a good thing as long as its constructive. Ignore the haters, pay attention to the folks filing bug reports and commenting.
The internal structure of the code matters, but it matters more if it works for its intended purpose. In general, refactoring will change how code works internally but will not affect how it is used. Same inputs and outputs.
You need to get something half-way
useful first, and then others will say
"hey, that almost works for me", and
they'll get involved in the project.
Linus Torvalds
Linux Times (2004-10-25).
It depends on why you are doing this. If it's to provide something useful and it's useful and has benefits that no other library has, then go for it. Just list the status and what's coming next.
If you are doing this to point to on a resume, get it in good shape (the code, not necessarily feature complete). Imagine a future employer poking around the code to see what it looks like, not downloading and running the code.
Whether you release the code in an incomplete state or not, it's always worthwhile having enough documentation to allow users to understand how to use the library.... even if it's only API docs. Make sure that anything incomplete is tagged as TO DO - it helps to maintain a target list of tasks to complete, and lets users know that the feature/method/whatever hasn't been forgotten.
Providing a set of code style/standard documents (perhaps with architectural notes on class relationships) allows other developers to contribute more readily, and in a manner that enhances the library rather than making it a hotch-potch of spaghetti code. It's never easy releasing a library, then having to refactor, while maintaining backward compatibility for users who have already taken up and are using that library in a production setting.
EDIT
Don't be afraid of criticism... it goes with the territory.
Some critcism can be constructive (take heed of that).
There'll be plenty of other people who criticise your code (for whatever their reason) without being constructive, or who just denegrate your work. The difference is, you've produced the goods, they probably haven't ever contributed to any OS product/library.
Users expect you to fix their problems immediately, or to write their code for them to use your library, or simply say "it doesn't work" without any explanation of what they mean. You have to learn to live with that 24x7x365.
But just once in a while, somebody will thank you for saving them hours of work, or for providing something useful... and suddenly all the stress and hassle feels worthwhile.
I read a document by Joshua Bloch, a pricipal software engineer at Google that talked a lot about the best type of API design. Basically, once you release it, it is more or less set. He says
Public APIs are forever - one chance to get it right
You can check out the slides here. It's definitely worth reading. I have a PDF of it as well; let me know if you need it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
What do you do with GitHub repositories you no longer maintain?
For whatever reason a project is started with a GitHub repository and then sometime later it's abandoned Perhaps it was an experiment that didn't work out. Perhaps you replaced it with a commercial product. Or perhaps you found a similar project to what you were doing and joined their efforts instead.
In the time your repository was alive, it attracted watchers and a few forks.
What do you do with it at that point? Is there a way to nicely indicate that repository is no longer maintained and to either check out the forks or a different project?
I'd do a single commit that removes all the source except for a README file that clearly states that you no longer have interst in the project (also copy the important parts of the README to the last commit log message, use git commit --amend if needed).
The README should explain that all the source code is still available as history. In addition the state of latest code should be described for maturity level: if it was used in production somewhere, it should be said here. If it was only an experiment and you never got it to compile correctly, then that should be said in capital letters. In the latter case, it might make some sense to just remove the code repository, though.
Obviously, the README should also contain the generic description of what your code does, but that should be already in the README.
Also try to put some words in the README that you expect potential users of that code to look for. Try to put those words close to the part that says that you're no longer maintaining the code.
The reasoning for this:
anybody interested in your source will still be able to get it (through history)
anybody trying to blindly merge your HEAD with his will immediately see that it's a bad idea (all source code will be removed and replaced with a README that explains why this happened)
I don't agree with the suggestion that if nobody has forked (and preserved the code), it's worth nothing. Perhaps the only reason somebody else has not taken over is that your project haven't been seen by enough many eyeballs.
If you believe that your code has any value (and I do mean anything above zero), then do not delete it. Just make it clear that the code has been abandoned.
Actually, I think pretty much the nicest thing you can do is to simply delete the repository. That way, the obsolete code doesn't show up in searches, for example.
The whole point of distributed version control is that no single repository is more important than another. If there is enough interest in the project, then one of the people who forked the repository will emerge as the new community leader. And if nobody forked it, then it probably wasn't worth preserving anyway.
I'd make a nice commit in the README file which basically states that this is here for historical reference, look at X Y and Z in order to see where this code went.
I prefix my projects with "deprecated." There are some posts on github's site regarding this, but it seems they won't budge. They want you to put a note in the readme. I'd prefer to put information in a relational database so you can sort on different fields, one of those being if the project is active or not.
I put my deprecated projects up there because there are concepts you can re-use. It is similar to your school work. Hopefully you can learn a lesson or 2 from it.
Walter
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Some time ago I observed a few people trying to start an open source project. About a week after the project started it more or less completely dissolved, partly due to issues with how the project itself was managed.
The ideas behind the project were however very well thought and a lot of people are still interested in seeing it realized. So far no one have made any serious attempt to recreate it but a few of us are thinking about doing so. Of course we don't want the project to end the same way it did last time.
Now to my question. How should one start a successful open source project, where successful is defined as "the project does not die unless no one is no longer interested in the software itself anymore?"
Nice question, though it's more worthy of a book than a simple article, IMHO. And I hope it comes as no surprise that most of the best advice is social, not technical.
Here are some observations in no particular order:
Don't make a big infrastructure investment up front Unless you're already an Apache committer (or somesuch), don't shop around for a sponsoring organization or host your own servers, etc. Get up on GitHub in 5 minutes and don't look back. Put your energy in features.
Lower the barrier for entry Don't make potential contributors jump through hoops or undergo a background check before you'll listen to their ideas. Open source projects are networked economies... you need the energy of others. Even misguided activity is better than no activity on your project. You can always steer the codebase in a better direction later.
Minimize custom code Don't write a custom logging tool or XML parsing API... there are open source implementations that are (1) good enough, (2) better maintained, and (3) better than yours will become anyway. The more energy you can focus on your core problem, the better.
Live on the edge People and organizations will only invest in improving your project if they will directly benefit. Eat your own dogfood. Create dependencies in your other projects (like with your employer) on your open source project, even if it isn't "perfect" yet. (Hint: software projects are never perfect, they're either works-in-progress or dead.)
GitHub is a good place because it makes it easy for someone with even just a little bit of interest to fork your project and apply his/her patches to share with others.
But it's really about the attitudes around your project more than where you host it or other simple considerations like that. Be benevolent, serious, and judicious, keep a community going even though it will be pretty small for a while, and so on. Accept patches that should be accepted, reject patches that should be rejected. Just be a good person, developer, and manager, and apply those skills to your project, and it should be fine.
You are saying it yourself. The most important thing is that it should have people who care enough about it to deal with the problems instead of abandoning.
If no one cares enough, it will die again. Try a different project where you do care enough.
"A lot of people interested in seeing it realized" means nothing if nobody will actually do the work, fight the fights and stay put.
I don't think it's set in stone, but for me the biggest point is that your project should fill a gap in the existing ecosystem. In other words, there has to a space for your project to live.
Other than that, I can say that the best way to stay motivated is to work together with people. You say that there are still a lot of people interesting in seeing it realized. So, why don't those people do something about it? Surely they can do something. I think a common misconception is that contributing to an open-source project means you have to be able to write code.
There's more to it:
Write documentation
Create graphical elements
Discuss features and roadmaps
promote the project
etc. etc.
Sure, not all of these points are applicable to every project, but trying to get people to commit to a project will eventually help you and/or your projectmembers to stay commited as well. You don't want to let down all the other folks on the project, do you? ;-)
This is kind of off-topic on SO, but I'll bite anyway.
Most FOSS projects are started by a SINGLE person. Other people come on board after this person has produced some code that does something vaguely useful. So if you want to start a project, do it yourself, set up a site on something like Google Code, and write some code. The last is the most important.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
What is the most useful strategy when your application throws an exception in the middle of the demo, in terms of keeping the client's mood still positive?
If your client doesn't trust you, there's nothing you can really do. I build trust with my clients so when something like this happens, they believe me when I give them an explanation. And when I tell them what I'm going to do to prevent future problems, I make sure to follow through.
Depending if this is a "final" demo or if its a mid-project demo will also affect whether you can really alleviate the customers' concerns. There's very little you can do to make the customer happy if it's the end of the contract and there's no more budget for testing and bug-fixes.
One generic strategy I've used: if you have someone in the room document the exception/problem in front of the customer and let them know it is going into the bug tracking system for investigation and testing, that will demonstrate to them due-dilligence and alleviate some concern. You, of course, need to follow through and make sure to fix the problem.
Just tell the truth but humorously, like saying apparently our software is still not that perfect, and we are keeping making it perfect.
don't ever lie or try to cover it up. clients are not dumb.
I'd say it depends on what stage you're in. If you're selling something, my experience is that it is always preferable to just bring static material for demonstration. Powerpoints are alright, but printed screenshots that the clients can toss around the table are unbeatable. It allows you to only show exactly what you want, in a very controlled manner, while still looking very professional.
If the client has already bought the project, and the demo is related to, say, a launch that's coming up, the best you can do is to smile and say "as you can see, we're still working out a few quirks"
I usually let the client know up front that I'm running off a live dev environment so we might see some weirdness. If I am aware of parts that have issues (inconsistent crashes..) I let the client know about them before I show that section (along with the fact that production won't do this and I am working on it already).
Update: based upon other responses, I agree that early demos with static material are better for generating discussion.
The last time I presented a project to a conference, I planned a live demo, but I actually had a set of slides headed "If you can see this, the live demo didn't work!" with big screen shots. Inevitably the live demo didn't work (it needed a globally routable IP address and this wasn't available) and the slides were called for.
I think it personally depends on your relationship with the client and how satisfied they are with your product this far.
I usually tell them it was bad data from testing or jokingly say that was a test to see how the application handles errors (if you have a generic, catch-all error message/page). You can also use the time to reiterate the importance of user testing/acceptance.
I've never done a demo where I didn't set expectations beforehand. If this is a work in progress, make sure they know that up front. This goes a long way towards keeping them positive. EVERYBODY has issues during demos. Just smile, tell the truth and continue.
Probably the best way to help keep your client positive is to project positivity and confidence yourself. If you seem unsure of yourself it'll show as being unsure of your app.
Possible strategies:
Telling the audience "we're all going to stay here until whoever did that owns up".
Complaining about the prevalence of evil monkeys.
Seriously, I'm majorly against public product demos. Don't attempt demos until you're 99.99999% sure the damn stuff works. And even then it's a bad idea, you're setting yourself up to fail with all the variables that can go wrong - which may not even be with your software. If you must do it, attempting to impress customers with a flashy UI is best done one-on-one. That's the way we've always done it.
Is this shipping product or still under development?
Assuming it's a shipping product, just recover and move on. Work the room while recovering (rebooting, restarting the app, etc.) and don't dwell on what happened. Customers understand stuff happens.
I was an applications engineer and this happened frequently. IMO, the key to recovering from this starts at the beginning of the relationship / sales process / demo, not one particular event. Establish trust and build credibility with your audience as early as possible. If you have this and an exeption gets thrown, the audience will probably trust you enough to think nothing about the software failure and just move past it. Yeah, you will have the occassional person looking to crucify you regardless of what you do but that comes with the territory.
Be honest if someone asks (they probably won't) and never talk negatively about your product. I also found when questioned about a fatal error, it helps, and they are very foregiving, if you can explain what happened in terms the audience understands. It demonstrates your knowledge of the software process and goes back to trust.
Write down the Exception and why/how it occurred IMMEDIATELY. Then they will see that you will be fixing it.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
It seems that the normal progression to join projects is to contribute for a while, earn the trust, then get accepted as a member of the community (i.e. having commit access).
Now, I already apparently know "the best way" of how to get involed, in a manner of speaking; this is not my question; what I was hoping to attain is: How did everyone else get involed? Surely not everyone has gone down the "find a project and submit patches" route - or have they? I dont happen to know anybody in the open source community, so I'm just itching to know...
Perhaps you already knew someone in a community and just fell into it? Maybe you were getting frustrated with some bug and started contributing regulary as a result? Maybe you did just spot a project on SourceForge...
Update:
It seems that the most common reason is simply scratching an itch, to quote singpolyma: "Looking for a project to contribute to is often not the right way." Instead, you should join the open source community by contributing to a project that you already know and use.
Important:
Please, please, please: Tell me about your specific experience, no general answers please. Also, answer only if you are either a project member or a patch contributor. Please do not give advice on how to join a community, this isn't the kind of answer I'm looking for. If you would like to give advice on joing a community, please answer in this other thread.
Great Answers:
Mark Harrison talks about Tcl, cx_Oracle, kap and orapig
singpolyma talks about DiSo and Greasemonkey
Pax talks about contributing to GnuCash because of his wife
Related:
How to get involved in an open source project
How Open Source Projects Survive Poisonous People (And You Can Too)
My personal anecdotes:
I got involved with the Tcl community when it was first starting out in 1991 or so. The mailing list and later the usenet newsgroup were pretty important to connect with people. I specialized in user evangelism and teaching, and eventually ended up writing two books about the subject. One of them is still in print after ten years:
http://www.amazon.com/dp/0201634740
Now I use a lot of Python, and really like the cx_Oracle package. Again I was active in the mailing list, and contributed a few patches.
I've made a couple of software packages available that I had written for work. By making them open source, I was able to get some nice contributions back, and since they were not the "secret sauce" of my employers at the time, they didn't mind sharing the code. The two most popular packages were
http://sourceforge.net/projects/kap/ The Kinetic Application Processor -- this was built when I was working on the China Internet backbone.
http://code.google.com/p/orapig/ - OraPIG, the Oracle Python Interface Generator -- it generated Python code to call APIs defined in the database, and includes an XML-RPC database interface.
Advice:
Instead of looking for projects to join, try contributing to projects you already use.
It's often difficult to jump into the "core" development, because (a) on a big project, that might be a pretty big chunk of code to understand, and (b) there are probably a core group of people already working on it.
So, suppose you like a certain piece of software and want to start contributing, you can start working around the edges. Here's a couple of concrete tasks that will help you to become integrated with the group.
write some test cases for bugs to add to the regression test suite.
browse through the bug database and find a bug to work on. This might be the best way to get into the core development.
look at the feature request database and see if there's a small task you can work on.
look for "user doc" requests... a lot of them involve writing example code which you can provide.
Good luck!
The way people normally get involved is:
you use the FOSS product in your day to day work
you notice a problem or a missing feature
you mail the maintainer to ask if this bug/missing feature is real
the maintainer says yes, this is a bug/missing feature
you decide to try to fix/add the bug/feature
you code like mad
you submit a patch to the maintainer
the maintainer laughs in or face or says "thanks very much!
If you repeat the last few steps a few times, the maintainer will probably give you commit access to the project's RCS repository, and then you can really become dangerous. But the bottom line is that it is up to you to do something i.e. write some code - merely being "interested" in a project is not enough.
I joined DiSo and Greasemonkey.
The best way I've found to get involved is to get in early in the life of the project, or just be very interested. With DiSo or the various github projects I'm on, it was the former, with my Greasemonkey contributions, the latter.
Looking for a project to contribute to is often not the right way. Use stuff and find out what you want to build/fix, then do that.
I did a little bit of patch work on GnuCash since my wife restarted work part-time recently after our kids were a little more grown up.
I would've rather had my eyes ripped out with a hot poker than re-install Windows but GnuCash was missing something that [a certain other accounting package] had so I told her I'd get it added.
As it turns out, they took my patch and made it a lot better before putting it in (to the point where maybe 1% of the final patch was my stuff) but at least we can now use GnuCash instead of that proprietary stuff. They were also incredibly responsive - from patch submission to patch availability was only a week or so and it was in the product three weeks later.
I also once investigated getting a patch into the process accounting in the Linux kernel but the effort required far outweighed my needs :-)
I don't contribute on a regular basis, more as-needed (find your itch and scratch it). There are some who make a hobby of it but I'd rather be spending my spare time with the kids and, unfortunately, my employer won't pay me to contribute elsewhere.
That last bit particularly galled me since:
the Linux patch would have greatly assisted our product (and a lot of others).
it was change in behavior of another of our products that degraded the usefulness of our product.
the solution was fairly simple, conceptually (the effort required was testing since a problem would have been high-impact [task switching] and very pervasive [everyone using Linux]).
it would have been quicker to code up the patch than the workaround we eventually implemented.
the workaround is a kludge (p'tooee).
now, nobody in the world has the benefit of our patch (including us).
What I did was pretty simple; I opened one.
I have been joined by one permanent developer, and other two who donate code behind the scenes. The project is in very early stages, so not many users have downloaded it.
What really helps an open source project is having a plugin architecture.
It's much easier to contribute a simple plugin for eg. a file format than to try to add something to the Linux kernel. This makes it a lot quicker and easier to build a community.
TODO: Please supply an anecdote.