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 3 years ago.
Improve this question
This isn't a question about code, but it's programming related. We have a web app that's ready for beta testing. Has anyone noticed any difference between open beta vs. closed beta in terms of the quality or quantity of feedback the testers give or any other factors?
With a closed beta, you can limit the number of users
This might not seem like a big deal but, consider this...
Closed Beta:
the user base is selected by requiring them to write a proposal in how they expect to use the app
you release a highly anticipated app to 100 users with no extra invites for the first month
those users use the program on a regular basis and pick through most of the really common bugs that slipped through the pre-beta release QC.
those users feel privileged to use the app so they brag to everybody about how much they love it (tons of free PR) and are less inclined to trash it because it's still a 'closed beta for a reason'
most of the commonly occurring bugs are identified in the first month and a limited number of invites are given to the first set of beta testers to progress into step 2 of beta
or, there are still a nightmarish number of bugs in the app and further invites are postponed for review until the next release cycle.
Open Beta:
you feel like your app is sufficiently polished so you release it to the masses as a public beta
the more objective users start to find and report bugs
unfortunately, the sheer number of bug submissions bloats the bug tracker so finding bugs becomes sufficiently difficult
since it's hard to find bugs, duplicates start popping up and the bug tracker bloats even more
you spend x amount of effort wasted trying to keep the bug tracker clean while also trying to fix bugs in the code
the less objective users give the app a shot and discover that 'not everything' works perfectly or works in a the way they expected (intuitive)
the less objective users run off to their little blogs and start making posts like 'OMG WTF srsly, [appName] sucks for reason [x] and reason [y] and [z]
all the little 'buzz bloggers' trample all over the name of your app because it makes them feel 'empowered' to publicly rant about any/everything
google indexes all of the blog rants because they contain a lot of indicative keywords related to your product so the top 2 pages that come up when you enter your apps name in google usually involve something along the lines of '[appName] sucks'.
One of the biggest benefits of a 'closed beta' is, you have the ability to control your work load based on how many users you allow and what types of users you allow.
You need an army of 'objective' users to back you up against the 'subjective' users because the ladder group's main purpose in life is to troll the web looking for an app to trash and create a lot of sensational anti-hype over; all in the name of attracting more traffic to their blog.
If you want a really good example of how to successfully run a closed beta look to Google.
with gmail they had a strictly limited closed beta to start
they fixed any obvious bugs discovered by the first round of beta testers
more invites are given out
then they start collecting new ideas of features to implement in their webapp from the beta users
they incorporate features while simultaneously fixing bugs
they dole out more invites
continue tracking features requests and bug submissions
when it's sufficiently polished they release it to open beta
GMail remains in open beta for 3 years
Why? Google is smart. If some random obscure bug pops up 2 years into open beta nobody can really trash google for it because it's still 'beta'. It's like Google's little way of saying, it's good but we're not completely satisfied with just good. Even if they didn't touch the codebase for the last 2 years of the beta, it still gives the impression of 'they're still perfecting it'.
Which leads me to the single most import point of why you'd want to limit the beta...
Once created, you can't change people's perceptions about your product
Watch this, "How to Ignore Marketing and Become Irrelevant in Two Easy Steps" to see what I mean. It's easily one of the most intriguing presentations I have seen.
Note: I've personally participated in multiple 'closed' betas. Namely, GMail, Google Wave, Boxee, Songbird, and a few others.
With a closed beta the people generally want to be there. They've either waited patiently in line to get an invite after signing up, or they've forgotten about it by the time it starts.
With an open beta, you get more people but they tend to be the "hey, this website is neat, I think I'll... OOH SHINY! runs off after a piece of tin foil" type.
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 6 years ago.
Improve this question
I understand this question is on the edge of being acceptable for stackoverflow, but still, I feel it is worth asking.
I've started using bitbucket.org a couple of days ago, attracted by mercurial hosting, 1 free private repository, a wiki and an issue tracker. Just what I needed for my project.
I have to say, the features offered and the website's interface looks great, and I didn't have any problems with mercurial-related things so far. However, after these couple of days I am doubting if I should move somewhere else while it still easy (I haven't advertised the wiki page yet, etc...), because I am running constantly into minor and major issues:
Over these few days, I've noticed a lot of site slowdowns and a couple of timeouts
I find the wiki to be rather limited in features (apparently it is based on Creole Wiki, never heard of it before). It does not allow for, for example, right-aligning of images, borderless tables, etc. (well maybe it does, but the documentation doesn't tell)
I've noticed some bugs in the wiki (a TOC-generation macro issue was reported over a year ago, but still not fixed)
I've tried making my wiki public by changing the settings in the Admin panel, but it doesn't work.
some more wiki things [like inserting images is awkward, creating a new page isn't very obvious, internal linking has it's issues as well, .. ]
the sort order in the newsfeed was wrong when I pushed a multi-commited changset
It's very nice (and brave!) they have an publicly accessibly issue-tracker for bitbucket, but seeing a list of over 500 open issues (28 pages * 20 issues per page) doesn't give the impression they are taken care of as well as they could. At least some issues could have been moved to some 'will-not-consider' state. I am afraid my bug report about the private/public wiki page will still be in there within one year
The blog has a lot of post about 'downtimes'
Now, I don't want to be too hard on the people/company running bitbucket, since it isn't clear to me whether it is practically run by a single person (in which case it is truly amazing) or a well-run company (in which case it is not :-). Perhaps they have some growing pains... It is hard for me to tell.
So, what I am looking for here, is some experiences of other people with bitbucket, and advice if I should hold out, and wait until things improve (good chances for this?). Or not.
Jesper from Bitbucket here.
We're a pretty small team. In fact, most of the time, it's mainly me who does sysadmin/coding. This leaves very little time to develop new things, and sometimes, it doesn't even allow me to keep everything running smoothly (slowdowns/short outages always happen when I sleep.)
I realize this won't work in the long run, and something needs to be done. Therefore, I have decided to hire a bunch of people, mainly developers, but also a dedicated sysadmin and 1 or 2 UI guys (to make things prettier/more functional.) I'm currently wading through applications, and there are a lot of promising applicants in there.
Wrt/ stability, I've also provisioned 2 (much) larger instances from Amazon, where we do our hosting. We're throwing more money at this. I'm migrating a bunch of users/repositories to these larger instances today, and immediately following this, we will focus on making things faster as well.
Question was asked 2010, but I think this question needs a slightly more updated answer. I've been using Bitbucket for a few months now and as far as I can tell, it is an amazing git hosting system. You are provided with an issue tracker, wiki, unlimited public/private repositories, team collaboration, etc. Also, I have not yet encountered any downtime or slowness. On top of all of this, Bitbucket has an amazing UI, making navigating through source code and branches amazingly easy.
I would definitely recommend using this, and SourceTree.
I have not tested Bitbucket with really massive commits.
We have been using BitBucket HG for about six months, and I have little doubt but that we will move to a different VCS. It merges things badly, makes mistakes on complex commits, hurts our productivity. I don't know which parts are HG vs BitBucket, but I don't even have time to find out. Of course this is happening at the worst time, we have a do or die deliverable in two weeks.
I've been using BitBucket for a few years 1 year at my past employer and 2 years at my present employer.
It generally works fine without any problems. However, about once a month there will be some slowness. Over this particular week there were outages spanning multiple workdays where things were slow or we were unable to push our code changes for about an hour here or there.
So to summarize, most of the time it is reliable, but occasionally, about one day a month on average it is not reliable.
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
I am working in a small team on some projects in my spare time. We are having the problem that we seem to go in circles and are not able to get our products developed - however this is not a problem during my day job. The lack of face-to-face communication seems to have a real impact on productivity.
Any examples of software or methodologies in use by the open source development community would be appreciated.
If you read the history of most open source projects, they start with one person doing a lot of the initial work. If there's a team, it's small, and one person actually leads the team.
To pick one example. In the Python community, they refer to Guido van Rossum as the Benevolent Dictator for Life (BDFL). His word is (more-or-less) final. In many cases there are folks don't agree with him -- but for the sake of the Python community -- they seem to acquiesce to his judgment.
I think every open source project has a (singular) lead programmer who assures that decisions get made, and made in a consistent way.
Back in the olden days, Fred Brooks (The Mythical Man Month) described "chief programmer teams". Same concept. Someone is in charge of the technical content. Emphasis on the one. Nowadays we call the the "architect" or some such term.
No real methodology here, but I think 2 things are important:
Have well defined goals and
responsibilities.
Let each developer
have the last say in how their
allocated part should be done.
In open source projects the only real and strongest motivation is the fun to be had coding the product. Relating to #2 above, if people are told what to do, and they don't agree with it, the motivation starts lacking. Of course there will always be a bit of give-and-take like in any other type of relationship.
Also about the face time, Skype is great for having face to face meetings, which I recommend at least once a week or month (depending on the size and momentum of the project)
This is a difficult question to answer because "open source projects" is a very broad selection of projects. I think the defining characteristic is the project has a single unifying goal (perhaps, a set of related goals).
Are you on any open source mailing lists? I am subscribed to my favorite distro's mailing list and the developers e-mail each other many times a day. Also, there are other avenues of communication such as IRC / Instant Messenger.
I am not a RoR developer, but I would suggest skimming through Getting Real for some inspiration.
My guess is that your private projects are all run and coded by developers. Developers are known to... keep on developing. The big difference, in my experience is that a company has experienced managers that can define when things are DONE. I'd recommend putting someone on the task of defining goals and decide when things are done.
I've been on some projects where we had a lot more talkers than developers. My inclination is to ignore the talkers and listen to the coders. Even then there's usually one person who is in charge of accepting patches. There may be political issues they have to tread lightly around, but for all intents and purposes they have final say.
Linus has had some fairly famous issues with the same problem. Take note of this thread from 2006: Talk is cheap. Show me the code.
One more thing. Since you say in the comments that you do have code, just a lot of rewrites, I'd highly suggest you read Eric Raymond's The Cathedral and the Bazzaar. Eric's a bit of a nutter actually, but the essay is priceless for anyone wanting to run a Free Software project.
I'd have a think about your and your team mate's motivation and goals in this project. Are they to:
a) Create an awesome product
or
b) play around with software, and learn some new things
Both answers are equally valid, and i'm guessing it'd be a mix with a leaning towards one or the other.
If it's more of (a) then look at suggestions on methodology etc. Maybe even consider forming a company around your awesome idea. Because making such a thing takes work.. and well you probably get enough of that at work.
If it's mostly (b) then you're going to have a harder time making an awesome product, but an easier time in that you can forgive yourself for not getting there right away and suffering multiple re-writes. And you will all be learning new skills each time you look at it and work together which are very applicable to your long term careers.
Firstly i suggest you all be clear with each other on why you are there. Then look at paring back on what you are planning on doing, and release early and release often. If your project is made up of three components and one is complete, then release that as a separate component and start building a community of users. This will pay off as these users will possibly help you with your code, plus form a solid core of users for the full product and let you assess how you are going early rather than later.
Good luck.
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 8 years ago.
Improve this question
I have a problem to solve that I think will take 4 days, but if I had a feature request sorted and a snapshot release then I reckon I could have it done in one. Superficially this creates a budget of 3 x my daily rate to get it the feature-request actioned.
So my questions are, have you ever paid an O/S project member to fix something for you? Did it work out OK? How did you sell the idea to your manager / colleagues and where did the money come from?
Most importantly how did you go about asking nicely? Is there an etiquette for these things? Are the project leaders likely to be receptive to the idea?
In case it matters, the software with the the missing feature is a JBoss project - the home of professional open source - and I'm able to claim expenses as I'm a contractor.
At work, we've had good luck hiring open source maintainers to enhance libraries that we use.
Here are some projects we've done in the past:
We needed to integrate Quake 2 with wxWidgets. We hired Vadim Zeitlin, a major contributor to wxWidgets. In less than 4 days, he built a wxQuake2 widget by adapting the Windows version of Quake 2.
Later on, we needed portable access to raw bitmaps. So we hired Vadim again, and worked with him to produce a new raw bitmap API. This involved a substantial bit of design work, but we really liked the resulting API, and we use it to this day.
At a later date, we hired another one of the core contributors to improve wxWidgets accessibility support. As it turned out, we ended up not using this code right away, for various technical reasons. But other people have been enhancing this code since then, and we hope to use it some day.
In other words, hiring open source maintainers is a lot like hiring any other kind of contractor. But some things are a bit different, too. Here's some advice based on our experiences:
You'll have the most luck if you want to enhance an existing project and release the changes as open source.
In general, you want to hire members of the core team. They have the best track records, they're the most productive, and they have the best chance of getting your changes merged upstream.
You want to get your changes merged upstream. If you don't, you'll be maintaining a local fork, which is a headache.
Before hiring, do some research. Who works on the features you care about? Are they somebody you'd enjoy working with? Read the mailing lists and glance at the version control history, and pick out a few people to approach.
During the design phase, there may be a bit of give-and-take. The developers are looking at the larger health of the project, and you're looking at the needs of a specific business. This has occasionally made negotiations a bit more complicated for us, but the final result has typically been a better design than we would have chosen on our own.
And most importantly, don't be shy. In any sufficiently large open source project, several members of the core team will already run consulting businesses. In smaller open source projects, you'll generally find several contributors who want to run consulting businesses.
And if you're still hesitant to approach somebody, you can always ask, "Do you know anybody who'd be interested in getting paid to work on $FEATURE?" If they're not interested, you haven't put them on the spot, and they may tell you who to ask.
On the whole, we've been impressed with the professionalism and productivity of open source maintainers, and I would recommend this route for others.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I'm working on a personal project and I'd love to be able to say at the end:"I've spend X hours on this project". Now one way to solve this, is to use a manual time tracker (worked from: to:). I've ran into problems with this, because I only manage to use it consistently for the first week or two. So I'd like to track development time automatically.
One idea I had was to insert a short script into the build process that that would insert a time stamp into a log file every time a build process is called. Later, I could analyze the intervals between each build and hopefully calculate a somewhat accurate picture of what's going on.
Does anyone else have an idea of how such a time tracking tool could be implemented?
Quick follow up based on the answers already provided:
Stop/start trackers aren't bad, but require a lot of discipline, something that I perhaps should be working on. But they dont work for me.
Specific app-tracking programs are great, but I'm current on Mac OS X.
My opinion is that you would greatly benefit yourself in keeping a light-weight development journal. Notes, sketches, times, dates, etc, designs. It's not an answer to your question, but it is a discipline that few developers have and one that they desperately need.
Life is busy and people must learn to track / budget their time and discipline themselves to take on good behaviors and habits.
I encourage you to fight and win this battle. Don't compromise something so easy to automation when there are greater gains if you improve your skills. You might also want to check out LifeHacker for some ideas.
A bit of a non-answer, but I hope you find it helpful.
If you use source control you can use svn (or any other) hooks on commit and checkout that log timestamps to a db, etc when you check your project out and when you check it back in.
The trick to making this work - and it is easiest on single developer projects - is to MAKE SURE you check your work in when you are done working for a period of time, and that you check it out immediately prior to doing actual work.
This might not be feasible for your project. Build process checking etc suffers from the same issues - namely that you might work for 3 hours and then build 8 hours after that.
We wrote a plug-in for our IDE (IntelliJ in our case) that keeps track of time spent per project automatically. The IDE's API lets you list for events like edits, changing windows, etc., so we log a record every time something like that happens. The reporting module looks at this raw data and determines the total time spent per project by comparing timestamps between records. If the difference is greater than 5 minutes, it assumes no work was done during this time.
It's not perfect and it's not 100% accurate but you do eliminate all the overheard of manually tracking this stuff yourself through some external tool.
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
Sooo...it's only sort of programming related, but I figure it's election day, right? Is there a single good reason why they aren't, not necessarily open source in that anyone can contribute, but open source in that anyone could inspect the source?
Voting machines aren't open-source because lobbyists for the "electrical till" industry successfully hoodwinked politicians not qualified to make technology choices into buying their snake-oil. This was accomplished with a mix of anti-FOSS FUD and good ol' fashioned bribery campaign contributions.
Update: I will try to post links here from time to time that show how vendors respond to critical examination. Feel free to add your own. (Pro-OSS–only: "the man" can make his own post!)
Interesting Email from Sequoia
In Belgium, the sourcecode for the voting machines is freely downloadable.
In the context of this discussion, you might find this paper interesting:
Secret-Ballot Receipts: True Voter-Verifiable Elections
It's written by David Chaum, the cryptographer responsible for DigiCash, among other things. From his bio page on Wikipedia, I also found End-to-end auditable voting systems.
Update! Now it seems we can see if this really works: First Test for Election Cryptography.
Looking back in time now, I've read a couple of articles on the experiment in Takoma Park, and this system actually seems different from the one described in the original paper. However, it is still by David Chaum, and still supports the end-to-end audit properties. The system is called Scantegrity II.
The reason they aren't open source, is because, as Kent mentioned, it wouldn't help. You could open source the code. But there's no way to ensure that the voting machine you are using is actually running the code that is open sourced.
There is no reason that open source code is better than closed source in this case.
How you voted must always remain a secret for obvious reasons. The ONLY real safeguard is the paper trail.
I WORKED with these machines and if so inclined I would have made malicious code that flips votes the way I wanted after 10 cast ballots to defeat whatever ridiculous Logic and Accuracy tests were thrown at the machine before deployment (We never went past one test vote).
Randomly pick a certain percentage of machines and compare the paper trail to the electronic tally. If Diebold had been confident of its machines then they would have insisted that this be the last step in any election.
Security Through Obscurity!
the problem is opensourcing the software would be a no-op.
They don't have any decent cryptography, and there has been demonstrated and relatively easy ways to contravene them simply by hot-swapping a ROM chip in the voting booth, or Having a device that augments the records in the record cartridge.
Youtube: Sequoia Part 1 Those with access can hack with programmed ROM chip
Youtube: Sequoia Part 2 Logic and Accuracy Test vs Election Mode with vote-stealing firmware
Youtube: Sequoia Part 5 Manipulating Sequoia Voting Results Cartridges from Precincts
#Mnementh The bad cryptography and the possibility to swap the ROM-chip has nothing
to do with open-sourcing the code? So there is the point?
There are only 3 logical reasons for opensourcing this code:
To put under scrutiny how the votes are counted to be certain its doing it right.
For somebody to be able to modify that code for their own needs.
To put the software into public domain so public committers can improve on it.
Points 1 and 3 are blown out of the water in terms of usefulness and "proving your vote counts" because you have no assurance that the code you are seeing/improving runs on these devices.
So that leaves only condition 2 being useful, and as you are not going to own your own voting machine, and have no need for one for anything more than nefarious causes or to simply prove their vulnerability.
For the majority of cases all it would mean is that there would be more information publically available on how to contravene these machines, so you would no longer need physical access to one in order to attempt reverse engineer their software and develop compromised ROM chips for use in said devices, grossly reducing the barrier to entry for the compromise of the voting system.
Granted, even in a non-opensource state this information can still leak, and you just have a false sense of security because you assume "theres no leak, I am safe", but on the contrary, if you open source it people will assume "hundreds of people have looked at the source code, I am safe" which is an equally bad false sense of security.
People are looking for a silver bullet safe way of voting, and sadly, there is none. Not without growing a race of purified peoples whom are brought up by non-committal monks in isolationist shrines to have a breed of people simply for the task of witnessing and counting votes accurately, whom are trained to be amoral and can't be bribed to switch the vote.
( It would sort of be like the 'dark angel' series except with voting agents instead of assassins, and we all know how that show works out, one of them would go rouge, we'd trust them, and they'd screw us all )
Because politicians buy them. Anything politicians get their hands in goes to shit, because 99% of the time they're only experience is in running for office, not doing things like adequately vetting hardware and software.
Also, kickbacks.
The truth hurts, doesn't it?
There is no specific reason not to open-source the software (and even opening the hardware-layout) of voting machines. It has no security impact, as some try to state, because if closed or open source, the ROM can be switched. The machine need some sort of verifier to check, if the code loaded is really the one certified for the election. Open-Sourcing would make no difference.
Because if they were they would not be able to blame inaccurate votes on calibration-errors on the touchscreen.
The people responsible have a "security by obscurity" bad meme stuck somewhere
The people building the software don't want to help competitors
The people building the software fear embarrassment
There are not enough people in the legislative process who understand the flaws in all of the above
So far, most replies have been technical in nature, but most likely, voting machines are not open source because the company under contract to develop them has no incentive to make them open source.
If a company develops an open source voting system, anyone came come around later to support that system. And, quite honestly, I doubt the government would accept the equivalent of a SourceForge project as the basis for an entire election.
Perhaps there should be an honest-broker authority that oversees the development of an open-source voting system, and contributors to that system should be vetted before they can view or commit source code.